With using Zing for Cassandra you don't need to spend time in tuning the JVM.
First, after stopping the Cassandra service on the host, install Zing. The fastest way is to start on the Zing quick start page using our package repository. Then change the JVM setting for Cassandra: JAVA_HOME=/opt/zing/zing-jdk8
Second, for production systems, the following additional Zing settings are required:
- Change the Zing memory reservation configuration to allow for more memory to be available for the file page cache as common Cassandra usage patterns are I/O intensive. By default, Zing reserves 75% of the the system's RAM for Java and leaving only 25% for the caches and all Linux processes.
To change this, start the command system-config-zing-memory, say "no" to "accept default" and accept all other default values except for the following: Change the "total memory to dedicate to Zing" from 75 to 60% and change the mode to "reserve-at-config".
- You don't need to change any JVM parameter in the cassandra-env.sh configuration. Zing is ignoring non-Zing -XX parameters. By default, Cassandra uses about half of the system RAM as -Xmx value for its main process and that's fine. With that, some additional Zing memory is still available for starting small management java processes.
- Disable the Cassandra GCInspector log messages as it might report long running GC phases which are of no concern when using Zing as those logged times are phases of the GC which are run in parallel to the application and don't pause the application. The log messages written to the Cassandra system.log are of the following pattern:
INFO [Service Thread] DATE GCInspector.java:284 - GPGC New GC in 300ms. GenPauseless
To disable them, add the following line to cassandra_install_location/conf/logback.xml:
<logger name="org.apache.cassandra.service.GCInspector" level="ERROR"/>
- For high performance Cassandra systems add or change in /etc/sysctl.conf or /etc/sysctl.d/zing.conf the following file system cache settings:
Those are standard Linux recommendations generally for databases to prevent spikes and waits in I/O.
- After rebooting the host, check the following:
Is enough Zing memory available to start diagnostic java processes?
Run "/opt/zing/zing-jdk8/bin/java -version" to check if it starts.
Is Cassandra using the correct -Xmx?
The command "zing-ps" should show slightly less than half the system RAM
as used for the Zing java process as Xmx.
In general, Zing runs better and faster with more RAM and more CPU cores as it offers more headroom to buffer application allocation spikes and allows more CPU resources to run the concurrent GC in parallel on many cores. With Zing, in contrast to many other JVMs, you don't experience a slow down or increased application pauses when adding RAM and increasing the Java heap.
For further questions about Zing configuration or system performance, please ask Azul Support.
In addition, you can request our Azul Cassandra Healthcheck performed by one of our Field Engineers, for instance if you plan a large Cassandra deployment.
Cassandra on Zing was never affected by the following bug as a fix in Zing was included in the Zing releases around the time this bug was triggered by changed added by JDK 8u161 / 8u162: https://issues.apache.org/jira/browse/CASSANDRA-14173