[ 
https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18056293#comment-18056293
 ] 

Dmitry Konstantinov commented on CASSANDRA-18831:
-------------------------------------------------

Early results for a very basic write benchmark to compare JDK17 vs JDK21, as 
well as G1 and ZGC.

It is CPU-intensive and synthetic (1 node, compaction and commit log disabled) 
but it can give some overall impression about a JDK-level impact.
Note: I've not done yet ZGC tuning, the default settings from the current trunk 
are used.
h2. Test scenario
 * Batch write test
 * 1 partition text column (size = 15 symbols)
 * 1 clustering text column (size = 10 symbols)
 * 5 value text columns (size = 10 symbols each)
 * inserts are done using 10-row batches
 * [^batch_profile_seq.yaml]
 * CLI:
{code:java}
./tools/bin/cassandra-stress "user profile=./batch_profile_seq.yaml no-warmup 
ops(insert=1,partition-select=0) n=15m" -rate threads=300 -node <IP> -mode 
native cql3 maxPending=256 connectionsPerHost=16 {code}

note: usage of uniform distribution for value columns in cassandra-stress 
creates a bottleneck in cassandra-stress itself inside random values generation 
logic, so seq generator is used there instead as a WA.
h2. Configuration
 * 1-node deployment
 * jdk-17.0.15+6 and jdk-21.0.10+7
 * compaction is disabled
 * commit log is disabled (due to lack of extra disk on my env to keep the IO 
rate)
 * trie memtable (64 shards), memtable_allocation_type: offheap_objects
 * GC: in case of G1 the following adjustments are made compared to the default 
configuration
{code:java}
-XX:ParallelGCThreads=16
-XX:ConcGCThreads=4 {code}

 * memtable_flush_writers: 8
 * 
native_transport_max_request_data_in_flight/native_transport_max_request_data_in_flight_per_ip
 increased to 2GiB
 * -Dcassandra.set_sep_thread_name=false
 * -Dio.netty.eventLoopThreads=2 (by default it is equal to number of cores we 
do not need that many ones, they only contend with other threads)
 * SSTable format: big

h2. Env
 * Cassandra node:
 ** m8i.4xlarge, CPU: Intel Xeon 16 vCPU, RAM: 64GiB
 ** disk: gp3, 50Gb, IOPS limit: 3000, throughput: 200
 * Cassandra stress node:
 ** c5.9xlarge, CPU: Intel Xeon 36 vCPU, RAM:  72 GiB

 
h2. G1 results

!image-2026-02-03-19-05-41-619.png|width=900!
||JDK17, G1||JDK21, G1||
|{{op rate                    : 213,229 op/s [insert: 213,229 op/s]}}
{{partition rate             : 213,229 pk/s [insert: 213,229 pk/s]}}
{{row rate                   : 2,132,292 row/s [insert: 2,132,292 row/s]}}
{{latency mean               : 1.4 ms [insert: 1.4 ms]}}
{{latency median             : 1.0 ms [insert: 1.0 ms]}}
{{latency 95th percentile    : 2.2 ms [insert: 2.2 ms]}}
{{latency 99th percentile    : 5.7 ms [insert: 5.7 ms]}}
{{latency 99.9th percentile  : 23.9 ms [insert: 23.9 ms]}}
{{latency max                : 389.5 ms [insert: 389.5 ms]}}
{{total gc count             : 38}}
{{total gc memory            : 333.640 GiB}}
{{total gc time              : 6.8 seconds}}
{{avg gc time                : 177.8 ms}}
{{stddev gc time             : 87.6 ms}}
{{Total operation time       : 00:01:10}}|{{op rate                    : 
230,427 op/s [insert: 230,427 op/s]}}
{{partition rate             : 230,427 pk/s [insert: 230,427 pk/s]}}
{{row rate                   : 2,304,270 row/s [insert: 2,304,270 row/s]}}
{{latency mean               : 1.3 ms [insert: 1.3 ms]}}
{{latency median             : 0.9 ms [insert: 0.9 ms]}}
{{latency 95th percentile    : 1.9 ms [insert: 1.9 ms]}}
{{latency 99th percentile    : 4.3 ms [insert: 4.3 ms]}}
{{latency 99.9th percentile  : 23.0 ms [insert: 23.0 ms]}}
{{latency max                : 802.2 ms [insert: 802.2 ms]}}
{{total gc count             : 30}}
{{total gc memory            : 358.018 GiB}}
{{total gc time              : 7.1 seconds}}
{{avg gc time                : 236.2 ms}}
{{stddev gc time             : 106.0 ms}}
{{Total operation time       : 00:01:05}}|

 So, for G1 we see not dramatic but visible improvement in throughput, in both 
cases to we pay with high max latency for it.

 
h2. GenZGC results

Here I've tried different number of client threads to find the throughput  when 
ZGC does not degrade due to an allocation stall.

An example of such stall:
{code:java}
[2026-02-03T18:32:04.578+0000][66.750s][5831][6108][info ] Allocation Stall 
(SharedPool-Worker-25) 450.500ms {code}
I've tried 300, 100, 80, 70, 60, 50 client threads.

Finally I've got good max latency for 50 threads:
||{{JDK 21, GenZGC}}||
|{{op rate                    : 90,155 op/s [insert: 90,155 op/s]}}
{{partition rate             : 90,155 pk/s [insert: 90,155 pk/s]}}
{{row rate                   : 901,547 row/s [insert: 901,547 row/s]}}
{{latency mean               : 0.5 ms [insert: 0.5 ms]}}
{{latency median             : 0.5 ms [insert: 0.5 ms]}}
{{latency 95th percentile    : 0.8 ms [insert: 0.8 ms]}}
{{latency 99th percentile    : 1.0 ms [insert: 1.0 ms]}}
{{latency 99.9th percentile  : 4.8 ms [insert: 4.8 ms]}}
{{latency max                : 26.1 ms [insert: 26.1 ms]}}
{{total gc count             : 247}}
{{total gc memory            : 52.568 GiB (wrong value, ignore it)}}
{{total gc time              : 211.1 seconds}}
{{avg gc time                : 854.5 ms}}
{{stddev gc time             : 2,033.0 ms}}
{{Total operation time       : 00:02:46}}|

So, in the test GenZGC can provide a low max latency but for more than 2x less 
throughput compared to G1. G1 allows to load CPU to almost 100% without a full 
degradation, GenZGC requires plenty of available CPU to provide good results.

 

cassandra-stress graph output for all the runs: [^jdk_gc.html]

> JDK21 support
> -------------
>
>                 Key: CASSANDRA-18831
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-18831
>             Project: Apache Cassandra
>          Issue Type: Task
>          Components: Build
>            Reporter: Achilles Benetopoulos
>            Assignee: Josh McKenzie
>            Priority: Normal
>              Labels: pull-request-available
>             Fix For: 5.1
>
>         Attachments: batch_profile_seq.yaml, 
> image-2026-02-03-19-05-41-619.png, image-2026-02-03-19-16-37-640.png, 
> jdk21-patch, jdk_gc.html
>
>          Time Spent: 9h
>  Remaining Estimate: 0h
>
> This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list 
> of supported Java versions, and extends that work to enable building and 
> running Cassandra under JDK21.
> The following commits comprise the changes included in the attached patch:
>  - 
> [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47]
>  - 
> [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897]
>  - 
> [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913]
>  - 
> [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to