The sync-chunk-writes server option added in 20w14a, when enabled, causes massive server lag when loading and saving chunks; both in singleplayer and multiplayer. This is most easily noticed when generating new terrain and traveling through portals, and is so severe that merely flying with elytra through new chunks easily brings the server to a halt, leaving the player suspended over a void while the chunks are being generated. Saving chunks also takes much longer (~10-20 times slower) and causes lengthy loading screens when e.g. changing dimensions or returning to the main menu.
Choice of storage medium has an effect; worlds stored in faster media, such as SSDs, experience less severe (but still very noticeable) effects than those in slower media, such as HDDs. Overall, opening region files in synchronous mode seems to limit the game speed more directly to the (slower) underlying disk speed.
This option is enabled by default and cannot be changed in singleplayer, rendering the game nearly unplayable when traveling long distances. Disabling it in a dedicated server by setting sync-chunk-writes to false in server.properties resolves the issue.
I've attached a video demonstrating the issue in singleplayer, a corresponding server log excerpt (notice the "Can't keep up!" messages and the time gap between "Saving chunks for level" and "All chunks are saved"), and a crash report from holding F3+C while flying over the unloaded chunks.
I have only tested this on Linux (Ubuntu), need confirmation on other OSes.
Update: I've attempted to reproduce this on Windows (64-bit, Java 1.8.0_51), but it does not seem to occur. Saving does still take slightly longer, but it's not much of an issue. This might have to do with driver differences between the two OSes. Other users have reported this issue to occur on Windows; the severity of this issue may be setup-dependent.
Update 2: Attempted running 20w15a on Linux with Oracle Java (1.8.0_241 64-bit) instead of OpenJDK, issue persists.
Linked issues
is duplicated by
Attachments
Comments
boq
For anyone voting, can you put information about your setup here? (mostly interested in OS and if it's SSD or spinning drive)
I have a HDD. TOSHIBA HDWD110.
Windows 10 pro.
FaRo1
Manjaro Linux 20.0.1 on a Schenker XMG A507-vsy, Minecraft data is on the HDD.
I just tested it with the SSD and it seems to be much better there (of course, SSDs are faster), but still noticeably slower than in past versions at least sometimes. When using the SSD, Minecraft does not appear with "100%" in the output of "iotop", which it does for minutes on the HDD.
Kubuntu Linux 18.04.1, Minecraft is on HDD (Seagate ST1000DM010-2EP102, 1TB, 7200RPM, 64MB cache)
Debian 8.10 (way old, I know 😃 ) and spinning HDD. Chunk loading can't keep up with elytra anymore.
Edit: I'd be happy if there was just a way to turn this feature off for singleplayer mode.
CubeTheThird
I experience this on the latest snapshot (20w22a), both on HDD and NVME SSD. Granted, on the SSD, the saving time is much lower (about 3 seconds), whereas on the HDD it is about 10-15 seconds.
I am on Arch Linux, 5.6.14-arch1-1 kernel.
This is my experience on this bug:
https://drive.google.com/file/d/1ny1qxYzQeT315XRoa1kRTr35cqt4xXsM/view?usp=sharing
And when the chunks are loading the whole world freezes.
May I know what the solution was to this?
When sync-chunk-writes=true, (for java dedicated server) it still causes a large amount of IO usage, slowing down chunk generation and overall server performance in proportion to the speed of the disk drive.
Was the solution just to set sync-chunk-writes to false ?
CubeTheThird
Yes, the solution is to set sync-chunk-writes to false.
wobst.michael
Rapidly flushing in-mem data naturally always comes with a performance hit. Depending on how how severe this affects you, you should indeed disable this option.
Im sorry, maybe i dont understand this. After running timings i see to be having the same issue, where can i edit that setting in my Minecraft server? Thanks!
CubeTheThird
@unknown, as per the ticket description, you have to set sync-chunk-writes=false in your server.properties file.
I know, this is gonna sound stupid, sorry in advance. But what if, there´s no Config like it in the server.properties? Should i write it down myself or am i doing something wrong?
CubeTheThird
Yes that's right, just add it yourself.
Did this regress?
I just pulled server.jar version 1.16.2[1], running it in an otherwise empty directory, and `sync-chunk-writes` defaulted to `true` when running on Arch. Performance matched descriptions here. A naive reading of the documentation following 1.16 PR3 would suggest that `sync-chunk-writes` would default to false under this scenario, given the platform was not Windows.
[1] (sha256: 2902ed3ff84e4f810a2c0620c6b6df9c3ef8488b272c61274d5eac2433876f39)
I think this is still an issue. At least in singleplayer. Saving worlds in 1.16.5 (and 1.17 snapshots) always takes minutes, but in 1.15.2 it took less than a second for me. I think this should be reopened.
I was having the exact same problem in 1.17.1. I was very confused why my server was lagging so much when players were exploring new chunks. When I found out it was due to this setting I was very surprised.
Like the opener of this issue stated this is terrible for world files stored on HDD's because HDD's aren't well-suited for random IO. Using the DSYNC option for file I/O doesn't give the OS a chance to coalesce these writes resulting in 100% disk activity at a puny write speed of around 700KB/s. While the disk is busy writing at those slow speeds the server is waiting for the write call to complete. With sync-chunk-writes set to false the disk is active for very short periods of time writing at several megabytes per second.
As expected moving the world files over to an SSD alleviates the issue somewhat.
https://www.minecraft.net/en-us/article/minecraft-snapshot-20w14a
The original motivation for this change was that it should prevent data loss or corruptions in the case of a crash. I don't think this is a good argument. As soon as the write system call has completed it's the operating system's job to commit the changes to disk at it's discretion. By default the linux kernel flushes queued data every 5 seconds, or when free memory goes below a certain limit. The only reason that the operating system wouldn't get the chance to commit to disk is when the entire system goes down unexpectedly (like power outages) in which case all bets are off in terms of data integrity anyway.
https://old.reddit.com/r/admincraft/comments/hn0g84/syncchunkwrites_causing_lag/
There are more people who complained about this and it seems that unofficial servers like paper ignore the sync-chunk-writes property and hide it as a command line flag instead.
For those reasons I think this issue should be reopened.
CubeTheThird
@unknown, this bug report is mostly about the issue affecting users in single-player, since it is only a setting in multi-player. The reason it is enabled for the purpose of preventing data loss is for Windows users specifically, and as such it is not enabled by default (again, in single-player) on Linux. The ability to change the default setting is the easy solution to not experience this problem on Linux servers.
For any additional discussions about bug reports, please take them onto our subreddit.
Barteks2x
This could also be fully fixed by writing chunks to regions in batches instead of one by one, which I have implemented as a proof of concept mod (is it ok to link the code here?), while keeping the safety properties regarding data loss. It makes a huge difference with an HDD, time to save the world can go down from minutes down to the normal few seconds. This would likely also benefit servers, as it would allow to actually use that option without being forced to have an SSD.
This happens to me too. It says in f3 debug mode that my game ticks running with 5-20 ms but I opened my task manager and it using 100 % of my harddrive. In the latest snapshot it is impossible to fly with elytra.
I'm on windows 10.
CPU: Intel(R) Core(TM) i5-4570 @ 3.20 GHz
GPU: GeForce GTX 1050 ti
Ram: 8 GB