cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2901) Allow taking advantage of multiple cores while compacting a single CF
Date Fri, 05 Aug 2011 12:41:27 GMT

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

Sylvain Lebresne commented on CASSANDRA-2901:
---------------------------------------------

bq. Well, I changed the semantics of maxInMemorySize.

Oups, missed that, sorry. Nevermind then.

Patch lgtm, +1. I would deactivate the use of parallel compaction for the test by default
before committing though, as it is not what we care the more for.

About Stu remarks, the goal is to speed up a given compaction. It is clearly for people having
SSDs, so the goal is imho more about having compactions done as quickly as possible (to have
the more consistent possible reads in particular) rather than the catching up of compactions
being behind (which CASSANDRA-2191 solves indeed). Even without triggering major compaction,
you can have a minor compaction that takes time. If you have the I/O capacity and the idle
cpu, why not having those get done more quickly ?

As you mentioned, it is also useful for things like repair for which, let's be honest, the
"other efforts underway to make the tasks less like a major compaction" are only idea at this
point (not that they are bad idea or anything, let's not just consider them as done).

For CASSANDRA-1608, I admit it is less clear how useful exactly that will be with leveled
compaction. However, it is not clear that will be useless either and again, leveled compaction
is not the default compaction yet.

Anyway, I have to admit that it is not the ticket I care the more for, and it will likely
not be useful for everyone. However it's done, the complexity is really all in ParallelCompactionIterable
(the rest of this patch being mostly trivial refactorings), and that last one is completely
optional, so I don't see a good reason not to add this.


> Allow taking advantage of multiple cores while compacting a single CF
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-2901
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2901
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 0.8.4
>
>         Attachments: 0001-fix-tracker-getting-out-of-sync-with-underlying-data-s.txt,
0002-parallel-compaction.txt
>
>
> Moved from CASSANDRA-1876:
> There are five stages: read, deserialize, merge, serialize, and write. We probably want
to continue doing read+deserialize and serialize+write together, or you waste a lot copying
to/from buffers.
> So, what I would suggest is: one thread per input sstable doing read + deserialize (a
row at a time). A thread pool (one per core?) merging corresponding rows from each input sstable.
One thread doing serialize + writing the output (this has to wait for the merge threads to
complete in-order, obviously). This should take us from being CPU bound on SSDs (since only
one core is compacting) to being I/O bound.
> This will require roughly 2x the memory, to allow the reader threads to work ahead of
the merge stage. (I.e. for each input sstable you will have up to one row in a queue waiting
to be merged, and the reader thread working on the next.) Seems quite reasonable on that front.
 You'll also want a small queue size for the serialize-merged-rows executor.
> Multithreaded compaction should be either on or off. It doesn't make sense to try to
do things halfway (by doing the reads with a
> threadpool whose size you can grow/shrink, for instance): we still have compaction threads
tuned to low priority, by default, so the impact on the rest of the system won't be very different.
Nor do we expect to have so many input sstables that we lose a lot in context switching between
reader threads.
> IMO it's acceptable to punt completely on rows that are larger than memory, and fall
back to the old non-parallel code there. I don't see any sane way to parallelize large-row
compactions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message