Using the Continuous Mark Sweep (CMS) garbage collector

Change GC from Garbage-First to CMS.

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.
Note: For help configuring CMS, contact the DataStax Services team.

jvm.options

The location of the jvm.options file depends on the type of installation:
Package installations /etc/dse/cassandra/jvm.options
Tarball installations installation_location/resources/cassandra/conf/jvm.options

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.
    Note: 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.
Note: For more CMS tuning tips, seeSecret HotSpot option improving GC pauses on large heaps.

Procedure

  1. Open jvm.options.
  2. Comment out all lines in the ### G1 Settings section.
  3. Uncomment all the ### CMS Settings section.
  4. Restart the database.