cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7546) AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
Date Wed, 06 Aug 2014 15:57:13 GMT

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

Benedict edited comment on CASSANDRA-7546 at 8/6/14 3:56 PM:
-------------------------------------------------------------

Well, technically we never ever call addColumn() directly, but in 2.0 we haven't removed /
UnsupportedOperationException'd that path, so I'm not totally comfortable leaving it as a
regular int, as an external call to addColumn would break it (but then, this probably isn't
the end of the world). 

However, I actually introduced a double counting bug in changing that :/   ... and since we
don't want to incur the incAndGet every change, and we don't want to dup code, let's settle
for the possible race for maintaining size if somebody uses the API in a way it isn;t in the
codebase right now.

-However I think I would prefer to make size final in this case.-

Looking again, it's too ugly to make it final, so let's settle for the ugliness of it being
non-final, and revert to your behaviour here. This bit is soon to be superceded by 2.1 anyway,
so let's not agonise over the beauty of it.


was (Author: benedict):
Well, technically we never ever call addColumn() directly, but in 2.0 we haven't removed /
UnsupportedOperationException'd that path, so I'm not totally comfortable leaving it as a
regular int, as an external call to addColumn would break it (but then, this probably isn't
the end of the world). 

However, I actually introduced a double counting bug in changing that :/   ... and since we
don't want to incur the incAndGet every change, and we don't want to dup code, let's settle
for the possible race for maintaining size if somebody uses the API in a way it isn;t in the
codebase right now.

However I think I would prefer to make size final in this case.

> 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_6.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)

Mime
View raw message