Configuring the garbage collector

Select and configure a garbage collector (GC) to remove data from memory that is no longer in use.

Garbage collection is performed by a Java process, garbage collection, which removes data that is no longer needed from memory. For the best performance, use either the Garbage-First (G1) or Continuous Mark Sweep (CMS) collector. By default, DataStax Enterprise (DSE) uses the Garbage-First (G1) collector.

The primary differences between the collector options are:
  • G1 divides the heap into multiple regions, where the number of regions depends primarily on the heap size and heap region size. The G1 collector dynamically assigns the regions to old generation or new generation based on the running workload, prioritizing garbage collection in areas of the heap that will yield the largest free space when collected. Additionally, G1 makes tradeoffs at runtime optimizing for a pause target (which is configurable using -XX:MaxGCPauseMillis) to provide predictable performance.
  • CMS divides the heap into new generation (eden + survivor spaces), old generation, and permanent generation, and relies on many heuristics and configurable settings to optimize for performance.

G1 advantages

DataStax recommends G1 over CMS for the following reasons:
  • G1 supports large heap sizes (24-96 GB) without tuning. DSE systems, especially those with Search, Analytics, or Graph workloads, have enough RAM to run larger heaps.
  • G1 handles dynamic workloads more effectively than CMS. DSE systems typically have multiple workloads, such as reads, writes, compactions, search indexing, and range reads for analytics, etc.
  • CMS will be deprecated in Java 9.
  • G1 is easier to configure. The only configuration options are MAX_HEAP_SIZE and -XX:MaxGCPauseMillis.