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 collector, 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). By default, DataStax Enterprise uses the Garbage-First (G1).

The primary differences between the collector options are:
  • G1 divides the heap into multiple regions—the number depends primarily on the heap size and heap region size. And then dynamically assigns the regions to old gen or new gen based on the running workload. It prioritizes GC in areas of the heap which will yield the largest free space when collected. Additionally, G1 makes tradeoffs at runtime optimising for a pause target (which is configurable using -XX:MaxGCPauseMillis) to provide predictable performance.
  • CMS only divides the heap into new gen (eden + survivor spaces), old gen, and perm 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. DataStax Enterprise (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 levers are MAX_HEAP_SIZE and -XX:MaxGCPauseMillis.