[jira] [Updated] (CASSANDRA-20085) move CompactionAwareWriter.append to separate thread

["Jon Haddad (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-20085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jon Haddad updated CASSANDRA-20085:
-----------------------------------
    Summary: move CompactionAwareWriter.append to separate thread  (was: move compaction writer to separate thread)

> move CompactionAwareWriter.append to separate thread
> ----------------------------------------------------
>
>                 Key: CASSANDRA-20085
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-20085
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jon Haddad
>            Priority: Normal
>         Attachments: image-2024-11-15-09-45-51-450.png, image-2024-11-15-09-50-41-854.png
>
>
> I'm examining a 5.0 cluster, mostly default settings except these overrides:
> {noformat}
> cluster_name: "rokt-density"
> num_tokens: 4
> concurrent_reads: 64
> concurrent_writes: 64
> trickle_fsync: true
> endpoint_snitch: "Ec2Snitch"
> compaction_throughput: 0MiB/s
> key_cache_migrate_during_compaction: false
> {noformat}
> Here's a flame graph of compaction taken with these settings:
> {noformat}
> asprof -e wall -X '*Unsafe.park*' -X '*Native.epollWait' -I '*compaction*' 
> {noformat}
>  !image-2024-11-15-09-50-41-854.png|thumbnail! 
> and in reverse:
>  !image-2024-11-15-09-45-51-450.png|thumbnail! 
> It's clear we can get an easy win by moving the writing portion of compaction to a dedicated thread (ExecutorService.newSingleThreadExecutor() ?), instead of blocking in the same one.  For this use case, it would improve compaction throughput by about 2x.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org