[
https://issues.apache.org/jira/browse/CASSANDRA-8833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327678#comment-14327678
]
Benedict commented on CASSANDRA-8833:
-------------------------------------
Well, it certainly has turned out to be more complicated than expected. In
particular "shadowed" is something I would have liked to avoid.
The mistake I made when implementing this, apart from not realising LCS
required no overlaps, was to not expend a great deal of effort making it _more_
robust than the existing solution. Many of the problems encountered here have
exhibited in the prior framework, or in other new pieces that are unrelated,
just less frequently. Cleanup of compaction has been buggy since time
immemorial; bloom filters, index summaries and entire sstables have been left
allocated indefinitely until very recent fixes. Index summary redistribution
has had all of the same DataTracker problems. So an argument could be made that
this is actually helping us out, by exercising these codepaths more
aggressively. After a major overhaul, there was an oversight (CASSANDRA-8764)
which is probably to be expected, and is the impetus for this ticket. This
overhaul has fixed numerous problems prior as well as new.
Removing this will introduce its own risks (every line touched is a new bug in
waiting), and doesn't eliminate as much complexity as might be desired.
SSTableReader lifecycles are still approximately as complex due to index
summary redistribution. Bloom filter resizing (CASSANDRA-6633) will have the
same requirement. The same goes for shared resources.
Reference counting has been broken for a long time, and we are now in a safer
position than we have ever been (although improvements are still needed, such
as CASSANDRA-8568), and the latest bugs we are finding in 2.0 are known not to
affect 2.1. We wouldn't be there without this as an impetus.
So, many of the changes will not be rolled back, because they were necessary in
themselves. They were just less pressing. There would still be a significant
removal of code, though.
As to the improvement: the compaction "cliff" can be pretty significant if
you're compacting huge files. Possibly introducing several minutes (or longer)
of seriously degraded performance. If you compact tens of gigabytes you may see
your entire page cache wiped out. Even with SSDs that's going to be painful for
a period. Without SSDs it could be tens of minutes.
Other than that, I'll let everyone else reach a conclusion about this.
> Stop opening compaction results early
> -------------------------------------
>
> Key: CASSANDRA-8833
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8833
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Marcus Eriksson
> Fix For: 2.1.4
>
>
> We should simplify the code base by not doing early opening of compaction
> results. It makes it very hard to reason about sstable life cycles since they
> can be in many different states, "opened early", "starts moved", "shadowed",
> "final", instead of as before, basically just one (tmp files are not really
> 'live' yet so I don't count those). The ref counting of shared resources
> between sstables in these different states is also hard to reason about. This
> has caused quite a few issues since we released 2.1
> I think it all boils down to a performance vs code complexity issue, is
> opening compaction results early really 'worth it' wrt the performance gain?
> The results in CASSANDRA-6916 sure look like the benefits are big enough, but
> the difference should not be as big for people on SSDs (which most people who
> care about latencies are)
> WDYT [~benedict] [~jbellis] [~iamaleksey] [~JoshuaMcKenzie]?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
