Wululululu
Assigned
Reported
Comments
So I was just testing again:
[media]This is happening while just sorting my inventory to chests, I'm not even flying around, but when I try chunks don't load and these appear again:
[media]Interestingly the write IO workers persist minutes after disconnecting from the server.
Hi
I have this issue as well on my server (Core i7-3770 CPU @ 3.40GHz, 4 core 8 threads, 16 GB RAM), OS: Debian 9.
The save I use was created in 1.15.2.
I can provide logs, debug txt and a crash report. The crash report was with 1.15.2 datapacks installed, so I disabled them for the next start of the server. The issues still persisted.
Is there a way to upload logs without sharing them with all bug tracker users? I consider a lot of data in there as "sensible information".
But to further answer some of @unknown's questions:
The issue starts happening almost immediately after joining. I fly around a little with my elytra and the issues start happening after some seconds.
I monitored the CPU usage with top and interestingly it didn't spike, but it dropped significantly, often below 10% usage.
Next thing I monitored was Disk IO (with iotop).
For some reason minecraft 1.16 seems to be limited to around 250K/s DISK WRITE. My raid can usually handle about 40M/s, which isn't blazing fast by today's standards, but still enough for minecraft in the past. Another interesting part is, that there's 0 Read IO, while the writer is doing something. So I am starting to fly and chunks just don't load anymore. Then the "can't keep up" messages start to appear.
It seems that the chunk writer of 1.16 is blocking read access and does some serious funk in my world.
When I shut down the server, the writer still persists for quite some time. It looks like it's rapidly building some kind of chunk write queue and then slowly writes that to disk.
So just out of curiosity I flew the same route in my map, but in 1.15 (and with a restored backup of my world).
There's also a some IO happening on the same route, but lots of reads (chunk loading), far less writes, and no blocking of the chunk loading.
As I said, if needed I can provide lots of details, or a world download, or maybe a screenshare session. But I'd like to keep my data as private as possible.
Still confirmed for the current Snapshot 19w08b.
I have the same error using Oracle Java 10.0.1 in Debian 9.4
Yes, but maybe it was a mistake. For reference I uploaded shipwreck screenshots of the non Java (Windows10/Bedrock) Edition. They seem to not have this intended behavior. I know both versions right now do not offer feature parity, but Mojang/Microsoft said they want them one day to have it. So one edition clearly has it wrong here...
I reviewed many shipwrecks and this happens to a lot of them. It does not seem to be intended as the status of this bug may suggest. Please review it at least.
Happend for me too on my server. I cannot rejoin at the moment.
I'm too running a server on 1.9 and I'm having real trouble with keeping it stable. We've built a zombie afk farm out of a spawner.
In previous versions of MC it was possible to afk and have a server still running at around 700 to 1000 zombies. My server can be repeatedly crashed now at around 300 to 400 zombies spawned. The server spams these messages:
[Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 10630ms behind, skipping 212 tick(s)
And when the zombies reach critical mass the server declares itself as crashed and shuts down.
But memory isn't the problem. The server runs on debian and got 8GB RAM assigned in the java arguments. So I watched it happen while having the server output and "top" in two sessions open. The server starts spamming the "skipping ticks" messages at around 230 to 240 total entities, with a majority of zombies. The memory usage doesn't really go up. The problem is the single thread CPU load. Every zombies seems to increase the load on the one core that the server uses by about 0.3 to 0.4%. Once it reaches 100%, the server starts spamming the "skipping ticks" messages. I guess it's because the system tries to use more than one core for the server at that time to handle the above 100% load. The load goes down on one core to about 50% and another core load starts to rise with about 45% in the beginning, rising for every new zombie. I guess the minecraft server can't synchronize the load balancing that's happening here, so it will shut down eventually.
Affects 1.9-pre2
Still in 16w05b
Nope, not fixed. Just tried it in the latest Snapshot 16w05b &16w06a. Still in it.
Affects 16w07a and 16w07b too
Still in 15w42a
Confirmed 15w42a
Still in 15w38a, Can a mod label this Bug as "item deletion" or for the sake of it as "item duplication"?
I know it's not a duplication issue but item dupes are fixed fast. Loss of items due to a bug seems to be okay for years now...
As you might have guessed. It's still in 15w38a.
15w33c also
It's in 15w33c
Another week, another version it's in.
This time 15w32a on Windows 10 though,
Edit2: and 15w32b
Edit3: and 15w32c
Edit1: I just checked again. 1.7.10 was the last full release that didn't contain this bug and 1.8 was the first that did.
When I posted on Saturday I also tried Spigot for 1.16.1 and the bug was also present in their release.
Today I tried Paper for 1.16.1 and they seem to handle disk IO differently than vanilla/spigot. This bug isn't present in their 1.16.1 server (at the time of posting here it's release #21 for Minecraft 1.16.1).
I hope I don't break any rules by providing a workaround that relies on software by a non-Mojang party. But I wanted to at least share my knowledge with others who can't upgrade their servers to 1.16.1 due to this issue.