[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087850#comment-14087850
]
Benedict commented on CASSANDRA-7546:
-------------------------------------
bq. We probably mean "to the left" of... "before" or "after" are a bit
confusing here!
Yep, good catch!
bq. Volatile read of the wasteTracker in the "fast" path.
At the moment we mostly optimise for x86 for the moment, and it's essentially
free here as you say. Even on platforms it isn't, it's unlikely to be a
significant part of the overall costs, so better to keep it cleaner
bq. Adjacent in memory CASed vars in the AtomicSortedColumns - Again not
majorly worried here... I don't think the (CASed) variables themselves are
highly contended, it is more that we are doing lots of slow concurrent work,
and then failing the CAS.
Absolutely not worried about this. Like you say, most of the cost is elsewhere.
Would be much worse to pollute the cache with padding to avoid it.
> AtomicSortedColumns.addAllWithSizeDelta has a spin loop 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: 7546.20.txt, 7546.20_2.txt, 7546.20_3.txt,
> 7546.20_4.txt, 7546.20_5.txt, 7546.20_6.txt, 7546.20_alt.txt,
> 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)
