Tuning Java resources
Tuning the Java Virtual Machine (JVM) can improve performance or reduce high memory consumption.
cassandra-env.sh
- The cassandra-env.sh file is located in the installation_location/conf directory.
cassandra.yaml
- The cassandra.yaml file is located in the installation_location/conf directory.
jvm.options
The location of the jvm.options file depends on the type of installation:
Package installations |
/etc/dse/cassandra/jvm.options |
Tarball installations |
installation_location/resources/cassandra/conf/jvm.options |
Tuning the Java Virtual Machine (JVM) can improve performance or reduce high memory consumption.
About garbage collection
Garbage collection (GC) is the process by which Java removes data that is no longer needed from memory. To achieve the best performance, it is important to select the right garbage collector and heap size settings.
One situation that you definitely want to minimize is a garbage collection pause, also known as a stop-the-world event. A pause occurs when a region of memory is full and the JVM needs to make space to continue. During a pause all operations are suspended. Because a pause affects networking, the node can appear as down to other nodes in the cluster. Additionally, any SELECT and INSERT statements will wait, which increases read and write latencies. Avoid a pause of more than a second, or multiple pauses within a second that add to a large fraction of that second. The basic cause of the problem is the rate of data stored in memory outpaces the rate at which data can be removed. For specific symptoms and causes, see Garbage collection pauses.
Choosing a Java garbage collector
- Heap sizes from 16 GB to 64 GB.
G1 performs better than CMS (concurrent-mark-sweep) for larger heaps because it scans the regions of the heap containing the most garbage objects first, and compacts the heap on-the-go, while CMS stops the application when performing garbage collection.
- The workload is variable, that is, the cluster is performing the different processes all the time.
- For future proofing, as CMS will be deprecated in Java 9.
- G1 is easier to configure.
- G1 is self tuning.
- You only need to set MAX_HEAP_SIZE.
- You have the time and expertise to manually tune and test garbage collection.
Be aware that allocating more memory to the heap can result in diminishing performance as the garbage collection facility increases the amount of database metadata in heap memory.
- Heap sizes are smaller than 16 GB.
- The workload is fixed, that is, the cluster performs the same processes all the time.
- The environment requires the lowest latency possible.
Setting CMS as the Java garbage collector
- Open jvm.options.
- Comment out all lines in the
### GI Settings
section. - Uncomment all the
### CMS Settings
section
Determining the heap size
You might be tempted to set the Java heap to consume the majority of the computer's RAM. However, this setting can interfere with the operation of the OS page cache. Operating systems that maintain the OS page cache for frequently accessed data are very good at keeping this data in memory. Properly tuning the OS page cache usually results in better performance than increasing the row cache.
max(min(1/2 ram, 1024 megabytes), min(1/4 ram, 32765 megabytes))
- Heap size is usually between ¼ and ½ of system memory.
- Do not devote all memory to heap because it is also used for offheap cache and file system cache.
- Always enable GC logging when adjusting GC.
- Adjust settings gradually and test each incremental change.
- Enable parallel processing for GC, particularly when using DSE Search.
- The GCInspector class logs information about any garbage collection that takes longer than 200 ms. Garbage collections that occur frequently and take a moderate length of time (seconds) to complete, indicate excessive garbage collection pressure on the JVM. In addition to adjusting the garbage collection options, other remedies include adding nodes, and lowering cache sizes.
- For a node using G1, DataStax recommends a MAX_HEAP_SIZE as large as possible, up to 64 GB.
MAX_HEAP_SIZE
Hardware setup | Recommended MAX_HEAP_SIZE |
---|---|
G1 for newer computers (8+ cores) with up to 256 GB RAM | 16 GB to 32765 MB. |
CMS for newer computers (8+ cores) with up to 256 GB RAM | No more 16 GB. |
Older computers | Typically 8 GB. |
- Set the maximum heap size in the jvm.options file to
a high arbitrary value on a single node. For example, when using
G1:
-Xms48G -Xmx48G
Set the min (-Xms) and max (-Xmx) heap sizes to the same value to avoid stop-the-world GC pauses during resize, and to lock the heap in memory on startup which prevents any of it from being swapped out.
- Enable GC logging.
- Check the logs to view the heap used by that node and use that value for setting the heap size in the cluster:
If you don't see improved performance, contact the DataStax Services team for additional help.
HEAP_NEWSIZE
- 100 times the number of cores
- ¼ of MAX_HEAP_SIZE
-Xmn800M
A larger HEAP_NEWSIZE leads to longer GC pause times. For a smaller HEAP_NEWSIZE, GC pauses are shorter but usually more expensive.
See Recommended minimum memory for dedicated hardware and virtual environments.How Cassandra uses memory
- To perform reads, the database maintains the following components in heap memory:
- Bloom filters
- Partition summary
- Partition key cache
- Compression offsets
- SSTable index summary
This metadata resides in memory and is proportional to total data. Some of the components grow proportionally to the size of total memory.
- The database gathers replicas for a read or for anti-entropy repair and compares the replicas in heap memory.
- Data written to the database is first stored in memtables in heap memory. Memtables are flushed to SSTables on disk.
- Page cache. The database uses additional memory as page cache when reading files on disk.
- The Bloom filter and compression offset maps reside off-heap.
- The database can store cached rows in native memory, outside the Java heap. This reduces JVM heap requirements, which helps keep the heap size in the sweet spot for JVM garbage collection performance.
Other JMX options
Cassandra exposes other statistics and management operations via Java Management Extensions (JMX). JConsole, the nodetool are JMX-compliant management tools.
Configure the database for JMX management by editing these properties in cassandra-env.sh.
- com.sun.management.jmxremote.port: sets the port on which the database listens from JMX connections.
- com.sun.management.jmxremote.ssl: enables or disables SSL for JMX.
- com.sun.management.jmxremote.authenticate: enables or disables remote authentication for JMX.
- -Djava.rmi.server.hostname: sets the interface hostname or IP that JMX should use to connect. Uncomment and set if you are having trouble connecting.