Database Reference
In-Depth Information
If you are running on hardware (or even in the cloud) and are lucky enough
to have Cassandra on solid-state drives, there are a few settings you can change
to get even better performance. The first change that you will want to make is to
set
multithreaded_compaction
to
true
. The reason this value defaults to
false
is that compactions are usually I/O bound. With multithreaded compaction
enabled, every compaction operation will use up to one thread per core plus one
thread per SSTable being merged. This means a lot of extra disk access. If you are
running on SSDs, this additional I/O won't be a problem and your bottleneck for
compactions will likely become the CPU.
The other Cassandra options for tuning SSDs are
trickle_fsync
and
trickle_fsync_interval_in_kb
. These values control the intervals at
which fsyncs to disk happen. When doing sequential writes to SSDs, you want
to avoid sudden dirty buffer flushing from impacting read latencies. Setting
trickle_fsync
to
true
and giving a small interval (10MB is usually a good
starting point) should make the dirty buffer flushes forced by the OS less frequent.
JVM Tuning
There are a lot of options for tuning the Java Virtual Machine. The best changes
are going to be a result of your workload. There are a lot of “your mileage may
vary”-type suggestions. In the following sections, we discuss a few basic prin-
ciples that can be followed.
Multiple JVM Options
There are a few different JVMs available. The requirements for deciding which
JVM to use for Cassandra are pretty straightforward. It must, at a minimum, be
Java 1.6 compatible or greater. It should support whichever hardware and operat-
ing systems you are using in your infrastructure as well. Although it should run on
the IBM JVM and JRockit, the recommended JVM is the Oracle/Sun JVM. Dif-
ferent JVMs will give you different performance characteristics, and you will have
to experiment with which virtual machine is best for you and your environment.
