[ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072530#comment-14072530 ]
graham sanderson commented on CASSANDRA-7546: --------------------------------------------- Good point - I was mixing the two types of memory allocation in my head... that said I don't know when we are seeing this in production how long each AtomicSortedColumns instance lives. bq. they stick around until they fill up I assume you are referring to the memtables there... what defines "full" besides. - there is a hard(ish) memory limit in yaml - MeteredFlusher flushes high traffic stuff Basically, I'm just checking that we don't think our 100MB/s wastage may never trigger due to aggressive flushing... theoretically we must be wasting MUCH more than we are really writing, but I don't have numbers (I could look at the logs to get them) to see how often hints memtables were being flushed during this process and how big they were. > 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_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)