[jira] [Commented] (CASSANDRA-7819) In progress compactions should not prevent deletion of stale sstables

["Benedict (JIRA)" <ji...@apache.org>]

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

Benedict commented on CASSANDRA-7819:
-------------------------------------

Looking at this a little more closely, the first patch actually looks completely safe. We never have a MergeTask outstanding inbetween iterations. In fact, I cannot see why we have the MergeTask submittedly asynchronously at all, since we immediately synchronously wait on the result. The Deserializer is the only work done asynchronously, and it doesn't touch this code.  

If this weren't true, the changes above would not be sufficient; we would need to introduce some other synchronization, or simply delay this change until 2.1.

ParallelCI returns an Unwrapper(MergeIterator); the _Reducer_ inside this MergeIterator, on a call to getReduced(), submits a Runnable to an executor, during which we need to be certain the sstables in that collection remain available. This getReduced() method is called on computeNext(), which is called on either hasNext(), or next(). The Unwrapper always calls next() immediately after hasNext(), so there are never any left dangling, and _immediately_ calls FBUtilities.waitOnFuture()) on the result.

The only other places we call shouldPurge are: inside the regular CompactionIterable Reducer, which is not asynchronously executed, and synchronously inside doCleanupCompaction and Scrubber.scrub.

I am a little sleep deprived this second, so if you could double check my logic, that would be great. But it looks solid to me.

> In progress compactions should not prevent deletion of stale sstables
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-7819
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7819
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>              Labels: compaction
>             Fix For: 2.0.11
>
>         Attachments: 0001-7819-v2.patch, 7819.txt
>
>
> Compactions retain references to potentially many sstables that existed when they were started but that are now obsolete; many concurrent compactions can compound this dramatically, and with very large files in size tiered compaction it is possible to inflate disk utilisation dramatically beyond what is necessary.
> I propose, during compaction, periodically checking which sstables are obsolete and simply replacing them with the sstable that replaced it. These sstables are by definition only used for lookup, since we are in the process of obsoleting the sstables we're compacting, they're only used to reference overlapping ranges which may be covered by tombstones.
> A simplest solution might even be to simply detect obsoletion and recalculate our overlapping tree afresh. This is a pretty quick operation in the grand scheme of things, certainly wrt compaction, so nothing lost to do this at the rate we obsolete sstables.
> See CASSANDRA-7139 for original discussion of the problem.



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