Caleb Rackliffe created CASSANDRA-16158:
-------------------------------------------
Summary: Avoid Unnecessary Chunk Cache Usage During Compaction
Key: CASSANDRA-16158
URL: https://issues.apache.org/jira/browse/CASSANDRA-16158
Project: Cassandra
Issue Type: Improvement
Components: Feature/Compression, Feature/Encryption, Local/Compaction
Reporter: Caleb Rackliffe
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
