Cassandra Tuned Up Configurations
When there is a high load flows through Message Broker there can be Out Of Memory Scenarios occurs and it is needed to fine tuning Cassandra , in order to come out of them. Following are some of the tune ups for Casssandra, in addition to the the basic configuration options which can be used in a such situation.
Change the memory allocations of the JVM In cassandra-env.sh file to the following values. ( for a Server with 8GB memory)
MAX_HEAP_SIZE="6G"
HEAP_NEWSIZE="1500M"
Adjust the memory table flushing threshold in cassandra.yaml as below.
flush_largest_memtables_at: 0.5
Change the commit log related parameters to overcome the OOM issues that can be observed with larger message sizes.
commitlog_total_space_in_mb: 16
commitlog_segment_size_in_mb: 16
Tune Cassandra Concurrent Reads & Concurrent Writes in cassandra.yaml as below.
concurrent_reads (By defaults this is 32) : A good value is 4 concurrent_reads per processor core. Increase this value for systems with fast I/O storage.
concurrent_write (By defaults this is 32) : It is not need of tuning since write operation is usually fast. If needed, increase this value for system with many cores.
Tuning for Cassandra Write Operations
Cassandra write path is usually fast hence requires little tuning. The biggest performance gain for write is to put commit log in a separate disk drive.
Cassandra JVM Parameters Tunings
The following entries can be configured to fine tune Java heap for improved performance.
JVM Parameter | Description |
---|---|
-Xms${MAX_HEAP_SIZE} | Min Java Heap Size: Default to half of available physical memory |
-Xmx${MAX_HEAP_SIZE} | Max Java Heap Size: Default to half of available physical memory |
-Xmn${HEAP_NEWSIZE} | Size of young generation heap (1/4 of Java Heap) |
-Xss128k | Max native stack size of a thread |
-XX:SurvivorRatio=8 | Young Heap survivor ratio |