cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1181) kinder gentler compaction
Date Fri, 25 Jun 2010 21:26:50 GMT


Stu Hood commented on CASSANDRA-1181:

I'm -0 on changing the compaction thread priority, as opposed to using a solution like ecapriolo
has suggested. This solution might even backfire and cause worse read performance if compaction
loses enough priority that you end up with tons of sstables waiting to be compacted.

While 'sleeping' compaction threads manually is akin to building our own scheduler, we have
so much more information than the OS scheduler does that it will probably be worthwhile. The
ideal situation would be that while writes are incoming, compaction is running almost constantly,
so that it is fully amortized. That is, there should only be one possible cascaded compaction
at a time, and it should finish immediately before the next compaction becomes possible.

> kinder gentler compaction
> -------------------------
>                 Key: CASSANDRA-1181
>                 URL:
>             Project: Cassandra
>          Issue Type: Task
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>             Fix For: 0.6.3
>         Attachments: 1181.txt,
> I suggested this in a ML thread but it seems that nobody actually tried it.  I think
it's worth following up on:
> You could try setting the compaction thread to a lower priority.  You could add a thread
priority to NamedThreadPool, and pass that up from CompactionExecutor constructor.  According
to you have to run as root and
add a JVM option to get this to work.
> In particular, Brandon saw read latencies spike to 100ms during [anti]compaction
on a 2 core machine.  I'd like to see if this can mitigate that.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message