cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9486) LazilyCompactedRow accumulates all expired RangeTombstones
Date Mon, 01 Jun 2015 13:08:17 GMT


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|]
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:
>             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

View raw message