[
https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742095#comment-14742095
]
Robert Stupp commented on CASSANDRA-9738:
-----------------------------------------
Pushed another update with the following changes:
* Legacy IndexEntry objects / missing offsets: re-serializing seemed too
expensive to me but not having the offsets in key-cache is also bad. For 3.0+
IndexEntry structures, we have the offsets - so that's not a problem. For
legacy IndexEntry structures, it generates _all_ offsets. The change is that
the key-cache will include the calculated offsets even for legacy tables. This
eliminates the need to re-serialize the whole thing. (legacyIndexInfoSearch()
is gone.)
* Moved the offsets-"array" back to the end of serialized IndexEntry structure.
* Sizing the serialization buffers: Tried to find easily and cheaply accessibly
stats for partition size and (more important) serialized IndexEntry size for a
CF but didn't find anything. So I added a (poor man) stats to CFMetaData that
tracks the numbers to size the serialization buffers appropriately. These stats
are not persisted, just calculated during runtime - so it's not a "perfect"
thing. The problem with existing stats is that we know the mean partition size
but not the mean size of the ClusteringPrefixes which could be used to
initialize the poor-man stats during startup. (Note: current
TableMetrics.meanPartitionSize iterates over all sstables to retrieve the value)
> Migrate key-cache to be fully off-heap
> --------------------------------------
>
> Key: CASSANDRA-9738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9738
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Robert Stupp
> Assignee: Robert Stupp
> Fix For: 3.0.0 rc1
>
>
> Key cache still uses a concurrent map on-heap. This could go to off-heap and
> feels doable now after CASSANDRA-8099.
> Evaluation should be done in advance based on a POC to prove that pure
> off-heap counter cache buys a performance and/or gc-pressure improvement.
> In theory, elimination of on-heap management of the map should buy us some
> benefit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
