Java

Tuning the JVM – G1GC Garbage Collector Flags for Minecraft

After many weeks of studying the JVM, Flags, and testing various combinations, I have come up with these flags as the most ideal combination to use, backed with SCIENCE.

I strongly suggest these flags to start your server (Which BTW: You really should be using Paper instead of Spigot: https://paper.emc.gs – Paper is a drop in replacement for Spigot and all plugins should still work – but with paper, please do not ask for support in #spigot IRC channel – ask in #paper )

Use these flags exactly (only modify the Xmx and Xms) for max memory of 10GB and LOWER. These flags work and scale accordingly to any size of memory, even 500MB)

These flags help keep your server running CONSISTENT without any large spikes. CPU may be slightly higher, but your server will be overall more reliable and stable TPS.

If you are running with 10GB or less memory for MC, you should not adjust these parameters. (I use 10GB myself)

If you for sure need more than 10GB (Hopefully you are 150+ player server) use these changes:

    • -XX:G1MaxNewSizePercent=60
    • -XX:G1NewSizePercent=35
    • -XX:InitiatingHeapOccupancyPercent=15

Explanation of flags:

  1. -Xms matching -Xmx – Why: You should never run your server with the case that -Xmx can run the system completely out of memory. Your server should always be expected to use the entire -Xmx! You should then ensure the OS has extra memory on top of that Xmx for non MC/OS level things. Therefore, you should never run MC with -Xmx settings you can’t support if java uses it all.Now, that means if -Xms is lower than -Xmx – YOU HAVE UNUSED MEMORY! Unused memory is wasted memory. G1 (and probably even CMS to a certain threshhold, but I’m only stating what I’m sure about) operates better with the more memory its given. G1 adaptively chooses how much memory to give to each region to optimize pause time. If you have more memory than it needs to reach an optimal pause time, G1 will simply push that extra into the old generation and it will not hurt you (This may not be the case for CMS, but is the case for G1)

    The fundamental idea of improving GC behavior is to ensure short lived objects die young and never get promoted. With the more memory G1 has, the better assurance you will get that objects are not getting prematurely promoted to the old generation.

    G1 Operates differently than previous collectors and is able to handle larger heaps more efficiently. If it does not need the memory given to it, it will not use it. The entire engine operates differently and does not suffer from too large of heaps.

  2. UnlockExperimentalVMOptions – needed for some of the others specified
  3. TargetSurvivorRatio: I’m sure your all use to seeing this one suggested. Good news! It’s actually a good flag to use :DThis setting controls how much of the Survivor space is ABLE to be used before promotion. If survivor gets too full, stuff starts promoting to Old Gen. The reason behind this is to be able to handle memory allocation spikes.However, MC allocation rate for most part is pretty steady (steadily high…..), and when its steady its safe to raise this value to avoid premature promotions.
  4. G1NewSize Percent: These are the important ones. In CMS and other Generations, tweaking the New Generation results in FIXED SIZE New Gen and usually is done through explicit size setting with -Xmn.With G1, things are better! You now can specify percentages of an overall desired range for the new generation.

    With these settings, we tell G1 to not use its default 5% for new gen, and instead give it 50% at least!

    Minecraft has an extremely high a memory allocation rate, ranging to at least 800 Megabytes a second on a 30 player server! And this is mostly short lived objects (BlockPosition)

    now, this means MC REALLY needs more focus on New Generation to be able to even support this allocation rate. If your new gen is too small, you will be running new gen collections 1-2+ times per second!!!

    This is bad! You will have so many pauses that TPS has risk of suffering, and Spigot might be unable to catch up TPS with the cost of GC’s.

    Then combine the fact that objects will now promote faster, resulting in your Old Gen growing faster…. This is bad and needs to be avoided.

    Given more NewGen, we are able to slow down the intervals of Young Gen collections, resulting in more time for short lived objects to die young and overall more effecient GC behavior.

    if you run with larger heaps (15GB+), you may want to lower the minimum to say 30%, but don’t go lower than 30%. This will let G1 have more power in its own assumptions.

  5. InitiatingHeapOccupancyPercent/G1MixedGCLiveThresholdPercent: Controls when to include Mixed GC’s in the Young GC collection, keeping OldGen tidy without doing a normal OldGen GC collection.On larger heaps(10GB+), you can raise InitiatingHeap to around 20 to reduce CPU usage, but I wouldn’t go higher than that. And you also need to REDUCE the Maximum New Percentage to around 60. If you use 80% NewGen Max, you must keep this at 10 then. It doesn’t hurt to leave it at 10, but “effeciency wise” you can improve it to 20 if you reduce your new gen size, but if you start seeing Old Gen GC, lower it back.
  6. AlwaysPreTouch: AlwaysPreTouch gets the memory setup and reserved at process start ensuring it is contiguous, improving the efficiency of it more.

Also for Large Pages – IT’s even more important to use -Xms = -Xmx! Large Pages needs to have all of the memory specified for it or you could end up without the gains. That memory CAN NOT be used by the OS anyways, so let something use it!
Additionally use these flags (Metaspace is Java8 Only, don’t use it for Java7):

Code:
 -XX:+UseLargePagesInMetaspace

Thanks to https://product.hubspot.com/blog/g1gc-fundamentals-lessons-from-taming-garbage-collection for helping reinforce my understanding of the flags and introduce improvements!

————-
Update 5/24/2018: Added -XX:+ParallelRefProcEnabled

0

Async Development – Task Chain – Java Control Flow for Bukkit

Reposting because Google has bugged out and ended up dropping this from Google :/ So making it look new to get it back on Google.

So as any Bukkit developer knows, the API is not thread safe! And to make matters worse, there is no concrete Java Control Flow API in Bukkit.

However at Empire Minecraft our server very heavily depends on our MySQL Database to provide features. So running database queries on the main thread is common but undesired, and Java control flow is needed.

Running queries async creates complicated java control flow issues, need to run this query… now need to access the bukkit api, so return to Sync processing, oh wait, now I need to act again with another database query!

Easy to avoid all that java control flow trouble by running everything sync – but then performance can be hurt.

Node.JS / JavaScript has this problem in great detail, and turns code into call back hell, so there are plenty of Flow Control libraries out there like Q, Async, Chainsaw and more.

Therefor, to avoid Java running into this same callback mess, I wrote an elegant Java Flow Control system on top of the Bukkit Scheduler.

Read more

0

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 221 other subscribers

I am Senior Software Engineer and Entrepeneur. I am an enthusiast and love creating things. I operate my own side company in my free time called Starlis LLC, working in Minecraft.

I enjoy doing things right and learning modern technologies.