[
https://issues.apache.org/jira/browse/CASSANDRA-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882722#action_12882722
]
Jonathan Ellis commented on CASSANDRA-1181:
-------------------------------------------
To reiterate, this patch leaves the default behavior unchanged, but allows
decreasing CM priority as described above.
if you don't have enough capacity to both compact and handle read/write load,
then you're screwed. writing a manual scheduler that may or may not do
slightly better in the short run is not going to change that.
what we want to do is slow compaction down so that instead of short violent
bursts of CM activity you spread it out over a longer period of time.
> 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.
