[
https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14139341#comment-14139341
]
Benedict commented on CASSANDRA-7546:
-------------------------------------
I've uploaded a patch
[here|https://github.com/belliottsmith/cassandra/tree/7964-simultinserts], and
another [here|https://github.com/belliottsmith/cassandra/tree/7964+7926] which
combines it with another stress patch that reduces the risk of OOM (although
this risk is pretty low, and almost certainly not what you were hitting) - but
as you scale thread count up it becomes more of a risk
The main 7964 patch includes a couple of small bug fixes as well, and I've
tested it against your schema and some other related schemas that are trickier
to process.
One thing I would suggest considering is expanding the clustering column count
to increase the speed of generation, as 1200 items is still quite a few to
create for only sending 1 item, which might end up reducing contention server
side. Possibly reduce to only 30-40 items per tier.
> 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
> Fix For: 2.1.1
>
> 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_7b.txt,
> 7546.20_alt.txt, 7546.20_async.txt, 7546.21_v1.txt, hint_spikes.png,
> suggestion1.txt, suggestion1_21.txt, young_gen_gc.png
>
>
> 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.3.4#6332)
