CMS GC JVM Parameter Tuning Guide for HBase Clusters

When managing multiple HBase clusters, the default CMS GC configuration often leads to sub‑optimal performance, prompting a need for JVM tuning. This guide consolidates knowledge about CMS and offers a practical set of JVM parameters tailored for CMS‑based garbage collection.

CMS GC Key Points

CMS is a concurrent, mark‑sweep collector that minimizes long stop‑the‑world pauses.

It only collects the old generation; young‑generation collection is delegated to a separate collector (typically ParNew).

CMS works best when paired with a parallel young‑generation collector such as ParNew.

GC types include Young GC (Minor), Old GC (CMS), and Full GC, the latter being the most disruptive and should be avoided when possible.

JVM Parameter Configuration

The following parameter list can be used as‑is for most HBase deployments, requiring little to no adjustment:

-Xmx32g -Xms32g -Xmn1g -Xss256k
-XX:SurvivorRatio=2 -XX:MaxPermSize=256m
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:ParallelGCThreads=10
-XX:ParallelCMSThreads=16
-XX:+CMSParallelRemarkEnabled
-XX:MaxTenuringThreshold=15
-XX:+UseCMSCompactAtFullCollection
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:+CMSClassUnloadingEnabled
-XX:-DisableExplicitGC
-XX:+HeapDumpOnOutOfMemoryError
-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-Xloggc:/app/log/hbase/gc-hbase-REGIONSERVER-`hostname`-`date +%Y%m%d`.log

For heaps of 64 GB or larger, the -Xmn value can be increased to 2 GB while keeping other parameters unchanged or only slightly tuned.

Key Parameter Analysis

-Xmx, -Xms, -Xmn : Define maximum, initial, and young‑generation heap sizes. Proper sizing balances CMS efficiency and young‑generation throughput.

-Xss : Thread stack size; default 1 MB, typically reduced to 256 KB.

-XX:SurvivorRatio : Ratio of Eden to Survivor spaces; a lower value helps short‑lived objects stay in the young generation.

-XX:+UseParNewGC, -XX:+UseConcMarkSweepGC : Enable parallel young‑generation collection and concurrent old‑generation collection.

-XX:ParallelGCThreads, -XX:ParallelCMSThreads : Number of threads for Young GC and CMS GC; set according to CPU cores.

-XX:MaxTenuringThreshold : Number of young‑generation collections before promotion; default 15, usually left unchanged.

-XX:+UseCMSCompactAtFullCollection : Compacts memory during Full GC to reduce fragmentation.

-XX:+UseCMSInitiatingOccupancyOnly & -XX:CMSInitiatingOccupancyFraction : Trigger CMS based solely on the occupancy fraction (commonly 70‑80%).

-XX:+CMSClassUnloadingEnabled : Enables class unloading in the permanent generation (or metaspace) to avoid Full GC caused by class‑loader leaks.

Online Tools

GC parameter checking and optimization: https://xxfox.perfma.com

GC log analysis: https://gceasy.io/

Reference Documents

http://hbasefly.com/2016/08/09/hbase-cms-gc/

https://mp.weixin.qq.com/s/gddff77gPdi5s2Hc9HBtcg

https://mp.weixin.qq.com/s/euey8visBvINQNOF0AiACQ

While CMS works well for many workloads, larger heaps often benefit from the G1 collector; a future article will cover G1 tuning.