ElasticSearch’s Garbage Collector — CMS or G1GC ?
Like most of programming languages, garbage collector is crucial for Elasticsearch. After Elasticsearch 6.5, garbage first garbage collector (G1GC) is started to support. Then the following questions come to mind.
“Which type of garbage collector should I use? How to decide that?”
Before choosing the best of garbage collector, needs to find out which GC is using and understand each of GC. Default location of “jvm.options” file, under etc/elasticsearch .
There is a GC configuration part in this file as showing below.
Concurrent Mark Sweep (CMS)
Elasticsearch, in default, comes with Concurrent Mark Sweep (CMS) Collector. This type of garbage collector is designed for short pauses. As its name signifies, CMS uses application threads to trace reachable objects references concurrently. Because of the application threads are used by GC, pause time occurs. Every time of triggering CMS, the whole old gen is cleared.
CMSInitiatingOccupancyFraction parameter means that CMS won’t start until old gen’s occupancy rate reaches 75%. If JVM allocates too much memory, old gen of garbage collector is much larger than normal, as a result of all these, CMS trigger operation will be delayed. It also means that a lot of space for long-lived objects, CMS takes a longer time to clear large old gen.
Consequently and as a suggestion, to get the best performance from CMS, run the JVM with the low memory (less than 8gb).
Garbage First Garbage Collector (G1GC)
G1GC is not coming out the default garbage collector of Elasticsearch but it is very easy to enable, just give the following parameter.
G1GC works with the application threads like CMS, G1 splits the heap into 2048 region and region’s size between 1MB and 32MB. Using the application threads, it tracks all regions for decided to which region has more garbage than the others. Besides if it finds the live objects, evacuated them to other regions.
When G1GC is triggered, stop the world phase begins. It can wait until your MaxGCPauseMillis parameter. In the situation that delays in the application is tolerable, this parameter can be increased for maximizing throughput.
Heap size closely associated with region size. G1GC treats object as Humongous Object which has larger size than half of the region size. These objects use special region which is called Humongous Region(HR). If HR is not big enough for humongous objects, more than one region will be used. To avoid this, parameter -XX:G1HeapRegionSize can be increase but do not forget that continuously increase region size affects negatively because of the number of regions will decrease.
Conclusions
The default CMS garbage collector configuration works well for most cases. The G1GC can help with if JVM heap size is larger than 8GB. Keep in mind that G1GC does not remove pause times completely from garbage collection operation. It uses to concurrent and parallel phases to achieve shorter and more predictable pause times.
The following articles can help on the topic.
