[ https://issues.apache.org/jira/browse/CASSANDRA-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17301179#comment-17301179 ]
Michael Semb Wever edited comment on CASSANDRA-16072 at 3/14/21, 3:46 PM: -------------------------------------------------------------------------- bq. The patch breaks the CommitLogSegment's closing process (whether capacity becomes full, or endOfBuffer gets re-assigned before buffer becomes null). Investigating this further… CommitLogSegment depended on the {{compareAndSet}}, to keep {{allocatePosition < endOfBuffer}}. Given that the atomic add approach isn't applicable to this code, I have applied the ConstantBackoffCAS algorithm (see CASSANDRA-15922) here. \\ Patches - [3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_cas_improvements] – [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/482/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/482/pipeline] - [trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_cas_improvements] – [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/483/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/483/pipeline] was (Author: michaelsembwever): bq. The patch breaks the CommitLogSegment's closing process (whether capacity becomes full, or endOfBuffer gets re-assigned before buffer becomes null). Investigating this further… CommitLogSegment depended on the {{compareAndSet}}, to keep {{allocatePosition < endOfBuffer}}. Given that the atomic add approach isn't applicable to this code, I have applied the ConstantBackoffCAS algorithm (see CASSANDRA-15922) here. Patches - [3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_cas_improvements] – [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/482/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/482/pipeline] - [trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_cas_improvements] – [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/483/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/483/pipeline] > Reduce thread contention in CommitLogSegment and HintsBuffer by rewriting CAS > loops to atomic adds > -------------------------------------------------------------------------------------------------- > > Key: CASSANDRA-16072 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16072 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints, Local/Commit Log > Reporter: Michael Semb Wever > Assignee: Michael Semb Wever > Priority: Normal > Fix For: 3.11.x, 4.0.x > > > Follow up to CASSANDRA-15922 > Both CommitLogSegment and HintsBuffer use AtomicIntegers for the current > offset when allocating. Like in CASSANDRA\-15922 the loops on > {{.compareAndSet(..)}} can be replaced with atomic adds using the {{. > getAndAdd(..)}} method. > In highly contended environments the CAS failures can be high, starving > writes in a running Cassandra node. On the same cluster CASSANDRA\-15922 was > found, after CASSANDRA\-15922's fix was deployed, there was still problems > around commit log flushing and hints. No flamegraph was collected that > demonstrated the thread contention as clearly as was found in > CASSANDRA\-15922, but the performance fix proposed here hopefully is obvious > enough. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org