[
https://issues.apache.org/jira/browse/CASSANDRA-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882719#action_12882719
]
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: https://issues.apache.org/jira/browse/CASSANDRA-1181
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.6.3
>
> Attachments: 1181.txt, CompactionManager.java
>
>
> 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
> http://www.javamex.com/tutorials/threads/priority_what.shtml you have to run
> as root and add a JVM option to get this to work.
> In particular, Brandon saw stress.py 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.
