Database Reference
In-Depth Information
GC log rotation
# don't stick the date in the log name if rotation is on.
JVM_OPTS="$JVM_OPTS -Xloggc:/var/log/cassandra/gc.log"
JVM_OPTS="$JVM_OPTS -XX:+UseGCLogFileRotation"
JVM_OPTS="$JVM_OPTS -XX:NumberOfGCLogFiles=10"
JVM_OPTS="$JVM_OPTS -XX:GCLogFileSize=10M"
Hinted Handoff
This feature comes in very handy when one or more replica nodes are down or not
available while writing a row. In such a scenario, the coordinator node would keep a
copy of data in the system.hints table until the replica node(s) are up and running. Gen-
erally it is a nice feature, but if such failure happens on multiple nodes, it would in-
crease heap size on the coordinator node. The system.hints table holds the IP addresses
of the replica node and the actual data that needs to replay when the replica node
comes alive. During the bootstrap process, system tables would be loaded in memory
so a larger number of failures would mean bigger data in memory on the coordinator
node. Such scenarios may also result in data loss (until repair). By default this feature
is enabled. Disabling it might result in relatively smaller heap sizes and less GC activit-
ies. But for durable writes it is advisable to keep this enabled. By default the coordinat-
or will keep data in the system.hints table for 3 hours, i.e., a default value of
max_hint_window_in_ms configuration
in the
Cassandra.yaml
file. If
the replica node doesn't come up in this configured window time, it would be assumed
as a dead node and later when it comes up it will need to run repair and replicate data
from other nodes.
Heap Size Configuration
Generally for applications, it is recommended to keep heap size in the range of 4-8
GB; but if memory is less than 4 GB, we still should use half of it (~2 GB) for I/O op-
erations. You can modify JVM settings for heap size configuration in
cassandra-
env.sh
(look for
JVM_OPTS
).
JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS" -Xms1G -Xmx1G
-XX:+HeapDumpOnOutOfMemoryError^ -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
