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

•  Change the total memory to use for memtables to a decreased value as then Cassandra will flush the largest memtable when this much memory is used.   

           memtable_total_space_in_mb: 512

• 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.