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

Sylvain Lebresne commented on CASSANDRA-9486:
---------------------------------------------

As Benedict mentions above, expired tombstone are only part of the problem, and 
we have 2 other problems: 1) only cells "trim" the tracker and 2) we don't pass 
shadowed cells to the tracker. As a result, if we have many RT and the only 
cells we have are deleted by those RT, all RT ends up accumulated, even if we 
wouldn't need to. Let's maybe fix it all here.

On top of that, the tracker class is admittedly a bit ugly already and adding 
more special casing for expired tombstones doesn't particularly help. So I've 
pushed [here|https://github.com/pcmanus/cassandra/commits/9486] a suggested 
alternative that solves the problems described above and, I think, simplify the 
code in the process (partly thanks to commenting it).


> LazilyCompactedRow accumulates all expired RangeTombstones
> ----------------------------------------------------------
>
>                 Key: CASSANDRA-9486
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9486
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Benedict
>            Assignee: Marcus Eriksson
>            Priority: Critical
>             Fix For: 3.x, 2.1.x, 2.0.x, 2.2.x, 1.2.x
>
>         Attachments: 0001-9486.patch
>
>
> LazilyCompactedRow initializes a ColumnIndex.Builder to use its 
> RangeTombstone.Tracker, but it only calls update() with a RT argument, never 
> an atom. The Tracker only ever _adds_ if it receives a RT, never removes. So 
> all the RT ever seen for the partition (that have expired) remain in memory 
> until the compaction completes. To make matters worse, this then forces a 
> linear scan of all of these RT for each live cell we add, so this extra load 
> hangs around for a long time, and compactions stall.
> This issue is biting one of our users badly (at least, it seems likely to be 
> this issue), and there may be others. This user is not even making use of RT 
> extensively themselves, only collections (presumably with a complete 
> overwrite of the contents of the collection, resulting in a RT being 
> generated).
> Probably the best solution is to make the RT addition itself remove any 
> already present that are no longer helpful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to