Crash even with 4GB RAM
Brottweiler opened this issue · 5 comments
At first I was using a 1vCPU 1GB RAM server but had frequent crashes so I used a 2vCPU 4GB RAM server and it went better, but still crashed eventually.
I was generating the nether right now (5000 worldborder) and it crashed at 46% completion.
[13:06:38] [Server thread/INFO]: [Chunky] Task running for minecraft:the_nether. Processed: 46019 chunks (46.38%), ETA: 0:26:38, Rate: 33.3 cps, Current: -99, 107
[13:06:49] [Server Watchdog/FATAL]: A single server tick took 66.21 seconds (should be max 0.05)
[13:06:49] [Server Watchdog/FATAL]: Considering it to be crashed, server will forcibly shutdown.
Crash logs:
- https://gist.github.com/ec1fa724500df10040f875519046b70d#file-crash-2021-05-08_13-06-50-server-txt
- https://gist.github.com/ec1fa724500df10040f875519046b70d#file-crash-2021-05-08_13-43-27-server-txt
Do I need more than 4GB RAM or is there another issue? The other mods I have loaded other than Chunky, is Fabric-API, Spark, Lithium and Starlight.
After restarting and continuing generation, it crashed again at 92% completion.
2vCPU
This doesn't give any details, it means two cores but doesn't tell us how powerful this CPU is. For this, the model name is required.
This crash was forced by Minecraft itself - if there is no response in more than (default) 60 seconds then "Considering it to be crashed, server will forcibly shutdown", you can try increasing max-tick-time=60000
(for the pregenerating time) in the server properties.
Sounds pretty typical for that kind of hardware. There's multiple things that could be causing crashes. Most likely in your case either the garbage collector is getting overwhelmed because the CPU can't keep up with the rate of allocations while chunks are generating, OR the disk is too slow and chunks deciding to save took too long. The latter problem happens far more often on Fabric because it doesn't have the same optimizations to chunk saving that Paper does. It also occurs much more frequently with Starlight (which I see you have) simply due to the increased rate of chunk generation (and thus more chunks to save).
Sparing some details, obviously what I'm saying is your DigitalOcean instance is probably not the best choice, regardless of how many vCPUs and RAM you throw at it. Generally a dedicated server -- or even your PC will do better. As mentioned here try to go for a CPU that has the best single threaded performance while also having a few cores, and a good SSD. Amount of RAM only matters to a certain extent.
If you can't spare the time or money for that, using some work arounds like @RDKRACZ mentioned is your best bet. Increasing max-tick-time
is a good idea, although it doesn't really solve the problem especially if it still stalls out for twice as long and crashes anyway. You could try removing Starlight temporarily to allow the server to generate chunks slower, thus reducing the overhead on GC and chunk saving. Obviously you'd want to re-add it after being done with pre-generation since it does give good gameplay performance optimizations. Lastly, if nothing else works, you might just want to pause and restart the server more often until it's complete. I know it's not ideal, but that's pretty much the best you can do with the hardware and Fabric server right now.
@pop4959 thanks for the insight! I'll definitely try without Starlight in the future. And yes, the server hardware is not the greatest. I use it because it's cheap and I pay for the hour as the server isn't up for very long at a time.
No problem. 😄
I'm guessing you're done with your pre-generation now (seeing that the last time you crashed was at 92%). I'll close this issue for now since it's not really a bug in chunky, but more of a general problem with running Fabric/vanilla on less powerful hardware.
If you need help again consider joining the Discord server and visit the #chunky channel there, as there are usually more people who check that instead of Github.
2vCPU
This doesn't give any details, it means two cores but doesn't tell us how powerful this CPU is. For this, the model name is required.
Good point. I am using DigitalOcean, and cat /proc/cpuinfo
doesn't really help since the CPU is considered DO-Regular. It seems to be Intel, though.
This crash was forced by Minecraft itself - if there is no response in more than (default) 60 seconds then "Considering it to be crashed, server will forcibly shutdown", you can try increasing
max-tick-time=60000
(for the pregenerating time) in the server properties.
Makes sense. So I assume due to the intense generation, the server stalls for 60 seconds and then Minecraft decides it has crashed and shuts down. I'll try your tip!