[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17894340#comment-17894340
]
Maxim Muzafarov commented on CASSANDRA-19429:
---------------------------------------------
[~dipiets]
Sorry for the delay in providing the promised review. I did some local testing
and can confirm that getCapacity in a hot path causes acquiring unnecessary
locks, which we can avoid. I also agree with Brandon that the getSize and
getCapacity methods are not interchangeable to fix the issue, and CaffeineCache
when it's enabled is the suspect.
>From my point of view, the problem described here highlights the incorrect use
>of the getCapacity (whenever it's in a hotpath or not) method to determine if
>a cache is enabled or not, and the issue itself has a slightly broader scope
>as we have similar checks in 5.x.
So we should aim for the fixes for at least a few releases:
- 4.x
- 5.x and the latest
*For the 4.x branches,* the correct solution is to rely on a cached value "Is
the cache enabled or not", which could be built into the InstrumentingCache
itself and use it to fix SSTableReader for the 4.x only. I think this should
solve the problem described here, and the possible solution with minimal code
changes could look like this:
[https://github.com/apache/cassandra/pull/3644/files]
(I'm deliberately not touching other places to minimize the fix and follow the
"don't touch it if it works" principle.)
*For the 5.x branches,* I think we should create another issue and fix all the
places where getCapacity is called to determine if a cache is enabled or not
and change it to use a proper method in the DatabaseDescriptor to rely on the
Сonfig, as suggested by Stefan
([#3133|https://github.com/apache/cassandra/pull/3133/files]). This would be a
slightly bigger change, as we would need to take into account and probably fix
some invariants that we currently don't have:
- The setRowCacheCapacityInMB (and similar), which we use to set a new value
via JMX, doesn't currently change a corresponding property in the
DatabaseDescriptor (bug?)
- Can we disable/enable row cache (and other caches) at runtime by setting
capacity to zero? For example, if it is disabled by default and the NopCache is
set, we can't enable it (# ), but if it was enabled by default can we set
capacity to zero to disable it? (it seems we don't have any tests so far)
[~smiklosovic] wdyt?
> Remove lock contention generated by getCapacity function in SSTableReader
> -------------------------------------------------------------------------
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
> Reporter: Dipietro Salvatore
> Assignee: Dipietro Salvatore
> Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=10000000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
