[jira] [Commented] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory

["Benedict (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14068803#comment-14068803 ] 

Benedict commented on CASSANDRA-7546:
-------------------------------------

bq. I'm not sure my code (whilst not blazingly pretty) is insanely hard to reason about... 

I'm not suggesting it is by any means abhorrent, only that we can achieve the desired goal with fewer changes, so unless there's a lot of evidence that the extra complexity is worth it, we should stick with the simpler approach (this also means less pollution of the instruction cache in a very hot part of the codebase, which is a good thing). I would suggest running a stress workload with a fixed number of threads, with increasing numbers of partitions (from 1 up to > number of threads) and see how the curve changes, if you want to benchmark this closely.

As to (b): since we only ever acquire the lock when we are contending, it must always be inflated anyway, so this shouldn't be an issue.

> 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_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)