[
https://issues.apache.org/jira/browse/CASSANDRA-20085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRA-20085:
-----------------------------------
Description:
I'm examining a 5.0 cluster, mostly default settings except these overrides:
{noformat}
cluster_name: "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]
and in reverse:
[^image-2024-11-15-09-45-51-450.png]
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.
was:
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.
> 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: "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]
> and in reverse:
> [^image-2024-11-15-09-45-51-450.png]
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
