You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Matt Byrd (Jira)" <ji...@apache.org> on 2026/06/15 14:25:00 UTC
[jira] [Updated] (CASSANDRA-21465) cache bytesOnDisk in SSTableReader to avoid excessive allocations reading MaxSSTableSize guage
[ https://issues.apache.org/jira/browse/CASSANDRA-21465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Byrd updated CASSANDRA-21465:
----------------------------------
Attachment: Screenshot 2026-06-15 at 15.16.10.png
> cache bytesOnDisk in SSTableReader to avoid excessive allocations reading MaxSSTableSize guage
> ----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21465
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
> Reporter: Matt Byrd
> Assignee: Matt Byrd
> Priority: Normal
> Attachments: Screenshot 2026-06-15 at 15.16.10.png
>
>
> When running a sidecar polling on metrics and a large number of files per instance (e.g levelled compaction and O(10-100k) files) this particular endpoint generates a large amount of allocations:
> {code:java}
> maxSSTableSize = createTableGauge("MaxSSTableSize", new Gauge<Long>()
> {
> @Override
> public Long getValue()
> {
> return cfs.getTracker()
> .getView()
> .liveSSTables()
> .stream()
> .map(SSTableReader::bytesOnDisk)
> .max(Long::compare)
> .orElse(0L);
> }
> }); {code}
> One option is to just not collect this metric, but I imagine a lot of operators maybe running into this unintentionally.
> We should be able to cache bytesOnDisk on SSTableReader and avoid all the allocations when invoking bytesOnDisk (and the syscall to actually get the size).
> The stables should in general be immutable and hence caching this fine, modulo early-open which can be special cased and is often disabled.
> I think this is probably preferable to trying to keep this metric updated inline as stables are created/updated (a bit tricky with max).
> Another larger change we might consider is caching the descriptor.fileFor so more general consumers also avoid allocation here, this however is probably also a step to far in terms of the complexity benefit trade-off .
> One other simple win here is just to also remove the use of streams, for more predictable performance, I think the current chaining may be too complex for the jvm to optimise away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org