[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14062849#comment-14062849
]
graham sanderson commented on CASSANDRA-7546:
---------------------------------------------
A few random thoughts
1) for 2.0.x I'd be tempted (pending further review) to use something like my
patch
We could make this a global cassandra.yaml option and/or make it a per CF
setting, but I think we should just make sure it looks good and go with it
2) It might be nice to track approximate (updated without locks) max contention
count according to the read of contentionCount, and expose it as a gauge for CF
metrics - probably worth a separate issue
3) for 2.1.x We should probably avoid the the duplicate code by better
encapsulating the behavior in an object (possibly an expanded variant of the
ColumnUpdater), or move to the suggested 3.0.x approach
w.r.t. to 3)
a) It might be nice to do the updates very lazily at least under load, so as to
reduce overhead of per mutation partial tree copy-on-write by batching writes
(you'd have to roll back and start over in the case one atomic mutation failed
mid-operation)
b) Have you given much thought to racing reads...
> AtomicSortedColumns.addAllWithSizeDelta has a spin lock that allocates memory
> -----------------------------------------------------------------------------
>
> Key: CASSANDRA-7546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7546
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: graham sanderson
> Assignee: graham sanderson
> Attachments: suggestion1.txt, suggestion1_21.txt
>
>
> In order to preserve atomicity, this code attempts to read, clone/update,
> then CAS the state of the partition.
> Under heavy contention for updating a single partition this can cause some
> fairly staggering memory growth (the more cores on your machine the worst it
> gets).
> Whilst many usage patterns don't do highly concurrent updates to the same
> partition, hinting today, does, and in this case wild (order(s) of magnitude
> more than expected) memory allocation rates can be seen (especially when the
> updates being hinted are small updates to different partitions which can
> happen very fast on their own) - see CASSANDRA-7545
> It would be best to eliminate/reduce/limit the spinning memory allocation
> whilst not slowing down the very common un-contended case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
