Disclaimer: Unlike other types of flags, this one is very server-specific. Results may greatly vary between hardware configurations.
Scenario
I have a VPS, 16GBs of RAM, 6 vCPU and NVMe SSD storage.
Between 5-10 users connected concurrently on the server, that like to spread and explore, mostly alone, between all dimensions.
Forge 1.19.2 server configured with hilltty flags, 10 chunk view distance, and 8 chunk simulation distance.
Tried all kinds of both mods, and flags configurations (GCs, -Xmx, Aikars, etc..), to have stable tps on the server.
So far, Hilltty flags have been the ones to better perform on this environment.
Background
Minecraft is a game that, as versions increase, so do they're object allocation rates.
In my 1.19.2 client, over 50 MBs are being thrown into the heap every second, to be descarded soon after.
This increase affects servers, as well.
ShenandoahGC default heuristic, adaptive, does a good enough job with this allocations, during normal gameplay.
However, once chunkloading starts to happen, it quickly begins to be not enought to free java heap, and heavy GC pauses (>1s) will be present, resulting in rubberbanding, and the infamous "Server can't keep up" and "Player moved too quickly" events spamming your server console.
The solution to this issue, may very well be the compact heuristic.
Flags
To enable compact heuristics:
-XX:ShenandoahGCHeuristics=compact
To select number of GC Threads
-XX:ConcGCThreads=#
Compact heuristic
Unlike adaptative, that tries to have a balance between GC pause time, and amount of GC passes, compact tries to run GC as much as possible.
This results in java heap almost never reaching the maximum capacity, greatly reducing the heavy GC pauses.
As a side effect, max heap can be greatly reduced, due to the more common GC passes.
Example: On my server, memory allocation went tfrom 3.7 GBs, to only 664MBs. 1
It also decreased mspt2 from 19.9ms, to 13.3ms..
..and completely tanked my chunk loading speed.
Concurrent Garbage Collectors Threads
In my environment, the default behaviour of the JVM is to use as much threads for garbage collection as possible.
This causes Minecraft to have less processing power available, generating processes like chunkloading to lag behind, even if TPS is still in perfect 20.
To fix this issue, you can follow documentation provided on the Shenandoah wiki, to decrease the number of threads used for GC.
1/3 or 1/2 of the available cores should be enough, for most servers.
Example: In my server, I have 2 threads assigned to Concurrent GC, from 6 vCPUs available.
TLDR
Try -XX:ShenandoahGCHeuristics=compact on your server, and tinker with -XX:ConcGCThreads=#
It may do wonders on your server, or completely tank your tps. Testing is the only way to know for sure.
nikissXI
commented
1 year ago
Preface
Disclaimer: Unlike other types of flags, this one is very server-specific. Results may greatly vary between hardware configurations.
Scenario
I have a VPS, 16GBs of RAM, 6 vCPU and NVMe SSD storage. Between 5-10 users connected concurrently on the server, that like to spread and explore, mostly alone, between all dimensions. Forge 1.19.2 server configured with hilltty flags, 10 chunk view distance, and 8 chunk simulation distance. Tried all kinds of both mods, and flags configurations (GCs, -Xmx, Aikars, etc..), to have stable tps on the server. So far, Hilltty flags have been the ones to better perform on this environment.
Background
Minecraft is a game that, as versions increase, so do they're object allocation rates. In my 1.19.2 client, over 50 MBs are being thrown into the heap every second, to be descarded soon after. This increase affects servers, as well.
ShenandoahGC default heuristic, adaptive, does a good enough job with this allocations, during normal gameplay. However, once chunkloading starts to happen, it quickly begins to be not enought to free java heap, and heavy GC pauses (>1s) will be present, resulting in rubberbanding, and the infamous "Server can't keep up" and "Player moved too quickly" events spamming your server console.
The solution to this issue, may very well be the compact heuristic.
Flags
To enable compact heuristics:
-XX:ShenandoahGCHeuristics=compactTo select number of GC Threads-XX:ConcGCThreads=#Compact heuristic
Unlike adaptative, that tries to have a balance between GC pause time, and amount of GC passes, compact tries to run GC as much as possible. This results in java heap almost never reaching the maximum capacity, greatly reducing the heavy GC pauses. As a side effect, max heap can be greatly reduced, due to the more common GC passes. Example: On my server, memory allocation went tfrom 3.7 GBs, to only 664MBs. 1 It also decreased mspt2 from 19.9ms, to 13.3ms.. ..and completely tanked my chunk loading speed.
Concurrent Garbage Collectors Threads
In my environment, the default behaviour of the JVM is to use as much threads for garbage collection as possible. This causes Minecraft to have less processing power available, generating processes like chunkloading to lag behind, even if TPS is still in perfect 20. To fix this issue, you can follow documentation provided on the Shenandoah wiki, to decrease the number of threads used for GC. 1/3 or 1/2 of the available cores should be enough, for most servers. Example: In my server, I have 2 threads assigned to Concurrent GC, from 6 vCPUs available.
TLDR
Try
-XX:ShenandoahGCHeuristics=compacton your server, and tinker with-XX:ConcGCThreads=#It may do wonders on your server, or completely tank your tps. Testing is the only way to know for sure.Documentation
https://wiki.openjdk.org/display/shenandoah/Main#Main-Heuristics
Annotations
1 Value using Spark, with -Xmx flag removed, so JVM can allocate memory as needed 2 MiliSeconds Per Tick