[
https://issues.apache.org/jira/browse/CASSANDRA-16158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-16158:
-------------------------------------------
Assignee: Caleb Rackliffe
> 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
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.x
>
>
> 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.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
