[
https://issues.apache.org/jira/browse/CASSANDRA-21754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Konstantinov updated CASSANDRA-21754:
--------------------------------------------
Change Category: Performance
Complexity: Normal
Fix Version/s: 6.0.x
7.x
Status: Open (was: Triage Needed)
> Reduce contention on MemtablePool.SubPool#allocated
> ----------------------------------------------------
>
> Key: CASSANDRA-21754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21754
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 6.0.x, 7.x
>
>
> During a write to a memtable we increase allocated counter within
> MemtablePool.SubPool and check if it is crossed a limit to trigger a clean
> (flush). We have multiple threads which update and read the value via
> AtomicLongFieldUpdater. For a high write rate the field can become a
> contention point + we may have false sharing for other fields within the same
> MemtablePool.SubPool object. MemtablePool.SubPool is common across all tables
> on a node.
> To reduce the contention we can use the fact that we do not need to read the
> allocated value every time, it is only needed to check if we've crossed a
> threshold for the next flush.
> So, we can apply a sharding approach for this value: we can split the value
> to several sub-values which are updated by different threads independently
> (similar to LongAdder). There are several ways to deal with threshold
> tracking, for example we can have a smaller threshold for each shard value or
> do some reservation from a common value, etc (a subject to evaluate the best
> one).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
