Cassandra 5 JDK21 Command Line actions
Hello ZGC members, I work on the Apache Cassandra team implementing support for JDK21 in the upcoming Cassandra 5+ release. I need insight into JVM options providing comparable and perhaps improved performance compared to G1GC. Some work has been done using the previous defaults: https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c9.... Also, can you please provide the testing/benchmarking methodology used by Stefan Johansson when presenting at Devoxx. Hope to achieve greater outcomes together, Thanks, Vivekanand K.
Hi Vivekanand, I'm actually currently trying to figure out how much information I can share around the setup we used. I can summarize what is already public information from my presentations. I'm using Cassandra 4 and JDK 21, with tweaked command-line options (--add-opens and so) to get it to run properly. I try to do very minimal JVM/GC tuning apart from setting the heap size and enabling the use of NUMA and large pages. G1 is using a 31G fixed heap (-Xmx31g -Xms31g) to be able to make use of compressed oops, while ZGC is using a 32G fixed heap. The only GC tuning I do is setting a 50ms pause time goal (-XX:MaxGCPauseMillis=50) for one of the G1 runs to see how lowering the pause target affect the performance. The testing methodology is running the same scenario with more and more threads to add more and more pressure to the server instance. The server is running on its own host and it is a single node setup. The clients all run on a different machine and we use the cassandra-stress tool with more and more threads to generate the load. Regarding tuning, one of the big things with ZGC is that you generally should not have to do any tuning. That said, when using JDK 21 you need to supply the -XX:+ZGenerational option to enable the generational mode. In JDK 23 and later the generational mode is on by default and in JDK 24 ZGC is generational and it can't be turned off. Something to look out for when using ZGC is allocation stalls, those happen when ZGC can't collect and free up memory fast enough. Generally if you see allocation stalls, you need to increase the heap size to give ZGC more head room to complete the GC work in time. If the stalls happen due to unexpected spikes of allocations the SoftMaxHeapSize option can be used to set the heap size ZGC should aim at using, but can go over during spikes of allocations. For example -Xmx32g -XX:SoftMaxHeapSize=28g, would give ZGC 4g of "reserved head room" that will only be used when it can't keep up. I hope this helps, StefanJ On 2025-05-09 07:27, Vivekanand Koya wrote:
Hello ZGC members,
I work on the Apache Cassandra team implementing support for JDK21 in the upcoming Cassandra 5+ release. I need insight into JVM options providing comparable and perhaps improved performance compared to G1GC. Some work has been done using the previous defaults: https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c9.... Also, can you please provide the testing/benchmarking methodology used by Stefan Johansson when presenting at Devoxx.
Hope to achieve greater outcomes together, Thanks, Vivekanand K.
Hi Vivekanand, If you have not already found the general suggestions for tuning ZGC, you can find those here: https://docs.oracle.com/en/java/javase/21/gctuning/z-garbage-collector.html#... One of the more important parts on that page that is often missed when using transparent huge pages is not only setting transparent huge pages "enabled = madvise", but also setting "shmem_enabled=advise". I also tend to also set transparent huge pages "defrag=madvise" too. hths, Charlie On 5/9/25 4:00 AM, Stefan Johansson wrote:
Hi Vivekanand,
I'm actually currently trying to figure out how much information I can share around the setup we used. I can summarize what is already public information from my presentations.
I'm using Cassandra 4 and JDK 21, with tweaked command-line options (--add-opens and so) to get it to run properly. I try to do very minimal JVM/GC tuning apart from setting the heap size and enabling the use of NUMA and large pages. G1 is using a 31G fixed heap (-Xmx31g -Xms31g) to be able to make use of compressed oops, while ZGC is using a 32G fixed heap. The only GC tuning I do is setting a 50ms pause time goal (-XX:MaxGCPauseMillis=50) for one of the G1 runs to see how lowering the pause target affect the performance.
The testing methodology is running the same scenario with more and more threads to add more and more pressure to the server instance. The server is running on its own host and it is a single node setup. The clients all run on a different machine and we use the cassandra-stress tool with more and more threads to generate the load.
Regarding tuning, one of the big things with ZGC is that you generally should not have to do any tuning. That said, when using JDK 21 you need to supply the -XX:+ZGenerational option to enable the generational mode. In JDK 23 and later the generational mode is on by default and in JDK 24 ZGC is generational and it can't be turned off.
Something to look out for when using ZGC is allocation stalls, those happen when ZGC can't collect and free up memory fast enough. Generally if you see allocation stalls, you need to increase the heap size to give ZGC more head room to complete the GC work in time. If the stalls happen due to unexpected spikes of allocations the SoftMaxHeapSize option can be used to set the heap size ZGC should aim at using, but can go over during spikes of allocations. For example -Xmx32g -XX:SoftMaxHeapSize=28g, would give ZGC 4g of "reserved head room" that will only be used when it can't keep up.
I hope this helps, StefanJ
On 2025-05-09 07:27, Vivekanand Koya wrote:
Hello ZGC members,
I work on the Apache Cassandra team implementing support for JDK21 in the upcoming Cassandra 5+ release. I need insight into JVM options providing comparable and perhaps improved performance compared to G1GC. Some work has been done using the previous defaults: https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c9.... Also, can you please provide the testing/benchmarking methodology used by Stefan Johansson when presenting at Devoxx.
Hope to achieve greater outcomes together, Thanks, Vivekanand K.
participants (3)
-
charlie hunt
-
Stefan Johansson
-
Vivekanand Koya