Cassandra 3.0 or later: Enable GC logging

Share us

 

This is the second post related to Garbage Collection in Cassandra. In this post we will discuss how can we enable GC logging with G1 or CMS Garbage Collector. I already discussed pros/cons of G1/CMS Garbage Collector in previous post.

To enable the GC logs, and other parameters related to GC we should check jvm.options file in Cassandra conf directory. It may be available in below location.

Cassandra Package Installation /etc/cassandra/jvm.options
Cassandra tar ball installation install_directory/conf/jvm.options

##GC logging options — uncomment to enable
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintHeapAtGC
-XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintPromotionFailure
-XX:PrintFLSStatistics=1
-Xloggc:cassandra_log_directroy/gc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=15
-XX:GCLogFileSize=20M

To Set G1 as a Garbage Collector, un-comment the below lines:-

# Use the Hotspot garbage-first collector.
-XX:+UseG1GC
#
## Have the JVM do less remembered set work during STW, instead
## preferring concurrent GC. Reduces p99.9 latency.
#-XX:G1RSetUpdatingPauseTimePercent=5
#
## Main G1GC tunable: lowering the pause target will lower throughput and vise versa.
## 200ms is the JVM default and lowest viable setting
## 1000ms increases throughput. Keep it smaller than the timeouts in cassandra.yaml.
-XX:MaxGCPauseMillis=400

## Optional G1 Settings

# Save CPU time on large (>= 16GB) heaps by delaying region scanning
# until the heap is 70% full. The default in Hotspot 8u40 is 40%.
#-XX:InitiatingHeapOccupancyPercent=70

# For systems with > 8 cores, the default ParallelGCThreads is 5/8 the number of logical cores.
# Otherwise equal to the number of cores when 8 or less.
# Machines with > 10 cores should try setting these to <= full cores.
-XX:ParallelGCThreads=16  #[My Machine has 24 Cores, so kept it 16]

To set CMS as a Garbage Collector, un-comment the below:-

###CMS Settings

-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSWaitDuration=10000
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
# some JVMs will fill up their heap when accessed via JMX, see CASSANDRA-6541
-XX:+CMSClassUnloadingEnabled

Choose the right Heap Size:-

Cassandra automatically calculates the max heap size(MAX_HEAP_SIZE) based on formula 

max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB)
Cores/RAM MAX_HEAP_SIZE
CMS for (8+ cores) with up to 256 GB RAM No more than 16 GB.
G1 for (8+ cores) with up to 256 GB RAM between 16 to 64 GB.

#################
# HEAP SETTINGS #
#################

# Heap size is automatically calculated by cassandra-env based on this
# formula: max(min(1/2 ram, 1024MB), min(1/4 ram, 8GB))
# That is:
# – calculate 1/2 ram and cap to 1024MB
# – calculate 1/4 ram and cap to 8192MB
# – pick the max
# It is recommended to set min (-Xms) and max (-Xmx) heap sizes to
# the same value to avoid stop-the-world GC pauses during resize, and
# so that we can lock the heap in memory on startup to prevent any
# of it from being swapped out.
-Xms24G
-Xmx24G

 

I believe now we understand, how can we enable GC logging, specific parameter for G1 or CMS Garbage Collector and HEAP_SIZE configuration. 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.