[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077057#comment-14077057
]
graham sanderson commented on CASSANDRA-7546:
---------------------------------------------
Ok, thank you... yeah my only reason for recording something in the actual
codebase was to indicate that to the user that they had ultra heavy partition
contention that might be detrimental to performance, and they should perhaps
review their schema. Given that this may not be the case at all in 3.0 (i.e. it
may be gracefully handled in all cases), I'll try out locally with a WARN
statement instead. I'll probably do it at memtable flush anyway which has more
useful context (e.g. the CF in question), and would be less spam-y (i.e. one
warn with the number of contended partitions, though perhaps the contended
key(s) are interesting at a lower log level)... whether we include such logging
in the final patch I don't know.
> 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_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)
