Database Reference
In-Depth Information
Tweaking JVM
Cassandra runs in
Java Virtual Machine
(
JVM
): all the threading, memory management,
processes, and the interaction with the underlying OS is done by Java. Investing time to op-
timize the JVM settings to speed up Cassandra's operation pays off. We will see that the
general assumptions, such as setting Java, heap too high to eat up most of the system's
memory. This may not be a good idea.
Java heap
If you look at
conf/cassandra-env.sh
, you will see nicely written logic that does
the following:
max(min(1/2 ram, 1024MB)
and
min(1/4 ram, 8GB)
. This
means that the max heap depends on the system's memory as Cassandra chooses a decent
default, which is as follows:
• Max heap = 50 percent for a system with less than 2 GB of RAM
• Max heap = 1 GB for 2 GB to 4 GB RAM
• Max heap = 25 percent for a system with 4 GB to 32 GB of RAM
• Max heap = 8 GB for 32 GB onwards RAM
The reason to not go down with a large heap is that garbage collection does not do well for
more than 8 GB of RAM. A high heap may also lead to poor page cache of the underlying
operating system. In general, the default serves good enough. If you choose to alter the
heap size, you need to edit
cassandra-env.sh
and set
MAX_HEAP_SIZE
to the ap-
propriate value.
Garbage collection
Further down the
cassandra-env.sh
file, you may find the garbage collection setting
as follows:
# GC tuning options
JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC"
JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC"
JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled"
JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8"
JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=1"
JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75"
