GemFire: Java 17 preparation, and ZGC. Increased Stability, low latency collector
Article ID: 294471
Updated On:
Products
Issue/Introduction
Do you want to be able to increase the heap without needing to completely retune all GC settings and arguments?
Would you like to avoid needing to open tickets against GemFire due to the constant need to tune GC, due to ever-changing needs/growth of data in your environments?
Environment
OS: Linux
Resolution
Beginning with GemFire 9.15, GemFire is compatible with Java 17. Also with Java 17, ZGC, an ever-improving garbage collector, provides 1ms MAXIMUM pause times.
Most of the required tuning arguments should no longer be needed. You should simply need the following settings.
-XX:+UseZGC
-Xmx=<Total Max Heap> ==> YOU MUST GIVE PLENTY OF HEAP OVERHEAD
-Xlog:gc* ==>You'll want GC logging output with details for any GC issues
Beyond that, you shouldn't need any of the old standards, essentially required tuning arguments such as Xms, ParallelGCThreads, NewSize, NewRatio, any of the Tenuring threshold arguments, etc.
It is important to NOT prematurely optimize right out of the box. Use only the above 3 settings, with the necessary options to write the gc log output to a file, should be used initially.
Any issues you've had over time in tuning GCs while using GemFire in your environments should be minimized. ZGC is a very low pause collector as its primary goal. You should never experience any long pauses, and therefore the GemFire distributed system should be healthy and stable.
For full transparency, it is very important to realize that ZGC achieves this very low pause goal at the cost of more heap, and less throughput. This varies per application, workload, etc. However, going forward, ZGC is preparing to release a new Generational ZGC Collector, still with the low 1ms maximum pauses, but also requiring MUCH less heap, 50%, 60% less overhead required than currently released ZGC versions available with Java 17.
All of this is completely INDEPENDENT of heap size. You can grow your heap as necessary, as you add data, bring on new applications, and load, without another round of major GC tuning before you have stability.
If using ZGC in your GemFire environment, feel free to open a proactive health assessment ticket for our Support team to observe behavior. It can help us to determine whether additional tuning is found to be more optimal than the out-of-the-box light configuration.
Here is a wiki page describing many of the details of ZGC:
If you would like to utilize Gemfire eviction with ZGC, please review the following KB article on how to properly set the soft max heap size:
https://knowledge.broadcom.com/external/article/294483/gemfire-using-zgc-and-softmaxheapsize-se.html
Sharing a VIDEO where ZGC Low Latency is explained. A short 30 minutes which should be required for anybody needing to maintain the stability of JVMs with distributed systems.
Feedback
