[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071330#comment-14071330
]
graham sanderson commented on CASSANDRA-7546:
---------------------------------------------
Note w.r.t. deletioninfo... I'm a bit confused about who owns what.
On 2.1 (And I'm not 100% sure of the exact semantics of when you need to use
HeapAllocator.instance vs pure heap allocation, since I haven't looked at the
2.1 code much)
{code}
if (inputDeletionInfoCopy == null)
inputDeletionInfoCopy =
cm.deletionInfo().copy(HeapAllocator.instance);
deletionInfo =
current.deletionInfo.copy().add(inputDeletionInfoCopy);
updater.allocated(deletionInfo.unsharedHeapSize() -
current.deletionInfo.unsharedHeapSize());
{code}
However, current.deletionInfo.copy() is not done with the HeapAllocator, and
the passed inputDeletionInfoCopy's ranges are RE-copied (without using
HeapAllocator.instance) on some code paths inside the .add() method but not
others
> 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)
