[ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088738#comment-14088738 ]
graham sanderson commented on CASSANDRA-7546: --------------------------------------------- I ran my smoke test on this and it is as expected; I have added the patch (with a warn log statement on memtable flush if we have resorted to pessimistic concurrency for some rows) to our 2.0.9 beta env... I will try and repro there with a node down (though this cluster is pretty much limited by commit volumes under high load, so can't equal production concurrency), but that said I just want to check that everything is OK, before I patch a single node in production (also 2.0.9) On a separate note (I don't have access to a 2.1 cluster ATM), it would be interesting to try something similar to http://www.datastax.com/dev/blog/cassandra-2-1-now-over-50-faster with a node down & hinting as a test case for this on 2.1 > 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_7.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)