Using the Continuous Mark Sweep (CMS) garbage collector
For some deployments that have small heap sizes, Continuous Mark Sweep (CMS) performs better than Garbage-First (G1) garbage collector (GC). CMS requires manual tuning which is time consuming, requires expertise, and can result in poor performance when not done scientifically or if a workload changes.
Using CMS has the following disadvantages:
-
Manual tuning and testing that requires time and expertise.
-
Only supports heap sizes up to 14 gigabytes (GB). Allocating more memory to heap can result in diminishing performance as the garbage collection facility increases the amount of database metadata in heap memory.
|
For help configuring CMS, contact the DataStax Services team. |
Where is the jvm.options file?
The location of the jvm.options file depends on the type of installation:
| Installation Type | Location |
|---|---|
Package installations + Installer-Services installations |
|
Tarball installations + Installer-No Services installations |
|
CMS guidelines
Use the following basic recommendations when configuring CMS:
-
Only use CMS in fixed workload environments, that is the cluster performs the same processes all the time.
-
In environment that require the lowest latency possible.
G1 incurs some latency due to profiling.
-
Configure heap size:
-
For systems with more than 24 GB of RAM, configure a 14 GB heap and the settings from
CASSANDRA-8150. -
For systems with less than 24 GB of RAM, configure an 8 GB heap and use the default settings.
-
For systems that cannot support 8 GB heap (which are not usually fit for production workloads) use the default settings. This allocates ¼ of the available RAM to the heap.
-
|
For more CMS tuning tips, see Secret HotSpot option improving GC pauses on large heaps. |
Procedure
-
Open
jvm.options. -
Comment out all lines in the
# G1 Settingssection. -
Uncomment all the
# CMS Settingssection. -
Restart the database.
