[MC-177542] Chunk loading and saving is extremely slow when sync-chunk-writes=true

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 2

MC-178619 Can't normally save and exit a Minecraft world in the most recent snapshot Resolved

MC-187769 Chunk Generation is very slow (like really slow) and using very little CPU doing it Resolved

Attachments

chunklag.mp4

crash-2020-04-05_15.33.25-client.txt

log.txt

profile-results-2020-04-24_15.32.12.txt

Comments 20

Nagy Richárd 2020-04-20T16:03:00Z

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

boq 2020-05-22T07:07:14Z

For anyone voting, can you put information about your setup here? (mostly interested in OS and if it's SSD or spinning drive)

Nagy Richárd 2020-05-22T07:23:20Z

I have a HDD. TOSHIBA HDWD110.

Windows 10 pro.

FaRo1 2020-05-22T09:00:40Z

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.

phigraz 2020-05-22T17:31:21Z

Kubuntu Linux 18.04.1, Minecraft is on HDD (Seagate ST1000DM010-2EP102, 1TB, 7200RPM, 64MB cache)

10 more comments

rlavers 2020-05-23T18:16:36Z

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 2020-05-29T20:50:41Z

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.

Nagy Richárd 2020-06-05T08:14:53Z

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.

Mudassar Khan 2020-06-25T12:43:20Z

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 2020-06-25T12:56:36Z

Yes, the solution is to set sync-chunk-writes to false.

wobst.michael 2020-06-25T13:06:58Z

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.

Gaston Vionnet 2020-08-11T13:42:27Z

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 2020-08-11T14:01:51Z

@unknown, as per the ticket description, you have to set sync-chunk-writes=false in your server.properties file.

Gaston Vionnet 2020-08-11T15:45:13Z

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 2020-08-11T16:34:34Z

Yes that's right, just add it yourself.

Luc des Trois Maisons 2020-09-06T00:59:14Z

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)

L Sonder 2021-06-05T18:49:59Z

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.

goeiecool9999 2021-07-13T12:55:09Z

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 2021-07-13T20:42:59Z

@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 2023-12-29T13:28:51Z

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.