[
https://issues.apache.org/jira/browse/CASSANDRA-19596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916526#comment-17916526
]
Yuqi Yan edited comment on CASSANDRA-19596 at 1/23/25 9:14 PM:
---------------------------------------------------------------
Just for anyone who might be interested in this: After looking into how
Tracker.apply[1] is implemented I now understand that each attempt to update
the View is through compare-and-set method.
If update reaches contention (other thread was able to update the View first),
the next attempts will do the apply again so the assumption here is every apply
should create a new View instance (not modifying the old one) every time and
try to CAS update the View instance.
This patch looks correct to me and I did some quick testing like:
[https://github.com/apache/cassandra/compare/trunk...Yukei7:cassandra:19596-test]
[1]
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/Tracker.java#L167]
was (Author: JIRAUSER301388):
Just for anyone who might be interested in this: After looking into how
Tracker.apply[1] is implemented I now understand that each attempt to update
the View is through compare-and-set method.
If update reaches contention (other thread was able to update the View first),
the next attempts will do the apply again so the assumption here is every apply
should create a new View instance every time and try to CAS update the View
instance.
This patch looks correct to me and I did some quick testing like:
[https://github.com/apache/cassandra/compare/trunk...Yukei7:cassandra:19596-test]
[1]
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/Tracker.java#L167]
> IntervalTree build throughput is low enough to be a bottleneck
> --------------------------------------------------------------
>
> Key: CASSANDRA-19596
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19596
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Local/SSTable
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
>
> With several terabytes of data and 8 compactors it’s possible for the
> compactors to spend a lot of time blocked waiting on IntervalTrees to be
> built.
> There is also a lot of wasted CPU because it’s updated optimistically so most
> of them end up being thrown away.
> This can end up being quite painful because it can block memtable flushing as
> well and then a single slow CFS can block unrelated CFS because the memtable
> post flush executor is single threaded and shared across all CFS.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
