[
https://issues.apache.org/jira/browse/CASSANDRA-21637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114578#comment-18114578
]
Dmitry Konstantinov edited comment on CASSANDRA-21637 at 9/12/26 12:03 PM:
---------------------------------------------------------------------------
{code:java}
┌─────────────┬───────────────┬────────────────┬──────────────┐
│ op/s │ cache enabled │ cache disabled │ cache effect │
├─────────────┼───────────────┼────────────────┼──────────────┤
│ Before │ 340,201 │ 344,966 │ +1.4% │
├─────────────┼───────────────┼────────────────┼──────────────┤
│ After │ 339,252 │ 366,330 │ +8.0% │
├─────────────┼───────────────┼────────────────┼──────────────┤
│ code effect │ −0.3% │ +6.2% │ │
└─────────────┴───────────────┴────────────────┴──────────────┘ {code}
Flamegraphs:
[^noser_base_btiNoDoubleReadBefore_fileCacheEnabled_wall.html]
[^noser_base_btiNoDoubleReadBefore_fileCacheEnabled_cpu.html]
[^noser_base_btiNoDoubleReadBefore_fileCacheDisabled_wall.html]
[^noser_base_btiNoDoubleReadBefore_fileCacheDisabled_cpu.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheEnabled_wall.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheEnabled_cpu.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheDisabled_wall.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheDisabled_cpu.html]
The issue with chunk cache: if the eviction rate is high then we have a
contention on a common lock in Caffeine cache eviction path. I use uniform
distribution in my test, so it is a kind of worst case probably for the cache
was (Author: dnk):
{code:java}
┌─────────────┬───────────────┬────────────────┬──────────────┐
│ op/s │ cache enabled │ cache disabled │ cache effect │
├─────────────┼───────────────┼────────────────┼──────────────┤
│ Before │ 340,201 │ 344,966 │ +1.4% │
├─────────────┼───────────────┼────────────────┼──────────────┤
│ After │ 339,252 │ 366,330 │ +8.0% │
├─────────────┼───────────────┼────────────────┼──────────────┤
│ code effect │ −0.3% │ +6.2% │ │
└─────────────┴───────────────┴────────────────┴──────────────┘ {code}
Flamegraphs:
[^noser_base_btiNoDoubleReadBefore_fileCacheEnabled_wall.html]
[^noser_base_btiNoDoubleReadBefore_fileCacheEnabled_cpu.html]
[^noser_base_btiNoDoubleReadBefore_fileCacheDisabled_wall.html]
[^noser_base_btiNoDoubleReadBefore_fileCacheDisabled_cpu.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheEnabled_wall.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheEnabled_cpu.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheDisabled_wall.html]
[^noser_base_btiNoDoubleReadAfter_fileCacheDisabled_cpu.html]
The issue with chunk cache: if the eviction rate is high then we have a
contention on a common lock on Caffeine cache. I use uniform distribution in my
test, so it is a kind of worst case probably for the cache
> Avoid double chunk read for BTI small partitions during a select query
> execution
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-21637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21637
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 6.0.x, 7.x
>
> Attachments: image-2026-09-02-15-59-03-586.png,
> image-2026-09-06-17-35-44-923.png, noser_base_btiNoDoubleReadAfter_cpu.html,
> noser_base_btiNoDoubleReadAfter_fileCacheDisabled_cpu.html,
> noser_base_btiNoDoubleReadAfter_fileCacheDisabled_wall.html,
> noser_base_btiNoDoubleReadAfter_fileCacheEnabled_cpu.html,
> noser_base_btiNoDoubleReadAfter_fileCacheEnabled_wall.html,
> noser_base_btiNoDoubleReadBefore_cpu.html,
> noser_base_btiNoDoubleReadBefore_fileCacheDisabled_cpu.html,
> noser_base_btiNoDoubleReadBefore_fileCacheDisabled_wall.html,
> noser_base_btiNoDoubleReadBefore_fileCacheEnabled_cpu.html,
> noser_base_btiNoDoubleReadBefore_fileCacheEnabled_wall.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> BtiTableReader.getExactPosition() opens a data-file reader to verify the
> partition key when the trie payload is negative (means the partition small
> enough to have no row index entry). It then closed that reader, and
> AbstractSSTableIterator immediately reopened the same file at the same
> position. So, we read the same chunk twice in such scenario as well as run
> LZ4 decompression and CRC32 check twice. We can re-use the reader to avoid it.
> !image-2026-09-02-15-59-03-586.png|width=600!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
