[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-7546:
--------------------------------
Attachment: 7546.20_6.txt
I've attached a slightly tweaked version, making things a little clearer (IMO)
and removing some of the unnecessary comments, as well as fixing a couple of
bugs and removing the AtomicReference<Holder> to recoup the extra space we're
now using in the Holder.
I must admit I'm still not madly keen on the nested synchronized() calls - I
think they're a little ugly, and also increase call depth which is not ideal. I
also cannot find any evidence that invoking unsafe.monitorenter/monitorexit
would result in negative optimisations (this discussion on the relevant mailing
list makes no such assertion whilst discussing its potential removal
[http://openjdk.5641.n7.nabble.com/Unsafe-removing-the-monitorEnter-monitorExit-tryMonitorEnter-methods-td179462.html],
but suggests exposing them more safely), however mostly I think the usage is
clearer than nested calls passing the state of the method (isSynchronized is
esp. ugly to me). I am not deadset against it though. Perhaps [~iamaleksey] can
offer a third opinion?
Otherwise, WDYT [~graham sanderson]? Could you give this patch a test and see
how it behaves?
> 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)
