incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hanna <>
Subject Re: is multithreaded_compaction stable?
Date Sun, 16 Sep 2012 02:47:04 GMT
Generally the main knob for compaction performance is compaction_throughput_in_mb in cassandra.yaml.
 It defaults to 16.  You can use nodetool setcompactionthroughput' to set it on a running
server.  The next time Cassandra server starts it will use what's in the yaml again.  You
might try using nodetool to set compactionthroughput to different values to see if that helps.
 Generally you want to keep compaction throughput high enough so that you don't get behind
but low enough to not adversely affect read/write latency.

multithreaded_compaction is meant for special circumstances where you have extra disk IO laying
around, such as when you're running Cassandra on SSDs.  Some people have run it and had no
problem.  However there are a few open issues with it, which is probably where "unstable"
came from.  I would stick with the compaction throughput setting.



On Sep 15, 2012, at 7:57 PM, Alexander N. Spitzer <> wrote:

> We have a cluster using leveled compaction and there are only a couple
> CF. The cluster does not seem to be able to keep up with compaction.
> When running "top", I always see core that is 100% busy, which I think
> is most likely the compaction thread.
> I wanted to enable multithreaded_compaction, but someone told me it
> was "unstable". Does anyone have any experience with this parameter?
> p.s. I am new to cassandra, so sorry if this is a silly question.
> Thanks!
> -alex spitzer
> Cell: 617.407.2274
> AIM: AlexSpitzer
> GChat:

View raw message