[CASSANDRA-16158] Avoid Unnecessary Chunk Cache Usage During Compaction

• Type: Improvement
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 5.x
• Component/s: Feature/Compression, Feature/Encryption, Local/Compaction
• Change Category: Performance
• Complexity: Normal
• Platform: All
• Assignee: Unassigned
• Reporter: Caleb Rackliffe
• Created: 01/Oct/20 22:09
• Updated: 10/Oct/24 05:53

Description

We have at least some evidence from CASSANDRA-16036 that compaction can cause significant churn in the chunk cache for a mixed workloads. Conceptually, this makes sense, as the files compaction is scanning are destined for deletion. It seems like we could avoid most of the cache churn mess by having the ISSTableScanner implementations returned by SSTableReader during compaction use file handles that don't use CachingRebufferer. FileHandle.Builder#complete() already seems to roughly have the logic we would need to produce the correct (uncached) RebuffererFactory.

(NOTE: SSTableReader#getScanner(ColumnFilter, DataRange, SSTableReadsListener) is used on the read path, and we likely don't want to touch it here.)

Given that CASSANDRA-16036 settled on disabling the chunk cache by default in 4.0, CASSANDRA-15229 further segregates the negative effects of this, and it isn't entirely clear that the decompression/decryption cache is actually adding measurable value for any workload, this may not be a critical priority for 4.0.

Issue Links

• is related to: CASSANDRA-15229 Segregate Network and Chunk Cache BufferPools and Recirculate Partially Freed Chunks
• is related to: CASSANDRA-16036 Add flag to disable chunk cache and disable by default