Try changing the chunk length parameter on the compression settings to 4kb,
and reduce read ahead to 16kb if you’re using EBS or 4KB if you’re using
decent local ssd or nvme.
Counters read before write.
—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com
On Fri, Apr 5, 2024 at 9:27 AM S
follow up question on performance issue with 'counter writes'- is there a
parameter or condition that limits the allocation rate for
'CounterMutationStage'? I see 13-18mb/s for 4.1.4 Vs 20-25mb/s for 4.0.5.
The back-end infra is same for both the clusters and same test cases/data model.
On
Hi,
Unfortunately, the numbers you're posting have no meaning without context.
The speculative retries could be the cause of a problem, or you could
simply be executing enough queries and you have a fairly high variance in
latency which triggers them often. It's unclear how many queries / second
Hi All,
On debugging the cluster for performance dip seen while using 4.1.4, i
found high speculation retries Value in nodetool tablestats during read
operation.
I ran the below tablestats command and checked its output after every few
secs and noticed that retries are on rising side. Also there
we are seeing similar perf issues with counter writes - to reproduce:
cassandra-stress counter_write n=10 no-warmup cl=LOCAL_QUORUM -rate
threads=50 -mode native cql3 user= password= -name
op rate: 39,260 ops (4.1) and 63,689 ops (4.0)
latency 99th percentile: 7.7ms (4.1) and 1.8ms (4.0)
Hi All,
Was going through this mail chain
(https://www.mail-archive.com/user@cassandra.apache.org/msg63564.html)
and was wondering that if this could cause a performance degradation in
4.1 without changing compactionThroughput.
As seeing performance dip in Read/Write after upgrading from 4.0 to
