cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <>
Subject Re: Frequency of Flushing in 1.0
Date Mon, 27 Feb 2012 20:51:03 GMT
yes, reducing commitlog_total_space_in_mb will reduce the amount of space needed by the commit

> memtable_total_space_in_mb
controls how often sstables are flushed to disk, this does not really affect the commit log.
Other than the fact that a commit log segment cannot be deleted until the changes in the sstable
have been flushed. But commitlog_total_space_in_mb is the correct way to control that. 

Hope that helps. 

Aaron Morton
Freelance Developer

On 27/02/2012, at 4:48 PM, Xaero S wrote:

> The challenge that we face is that our commitlog disk capacity is much much less (under
10 GB in some cases) than the disk capacity of SSTables. So we cannot really have the commitlog
data continuously growing. This is the reason that we need to be able to tune the the way
we flush the memtables. From this link -
, it looks like "commitlog_total_space_in_mb" is the parameter to control the rate at which
memtables get flushed. Also it seems "memtable_total_space_in_mb" is also another setting
to play with.
> we are planning to do some load testing with changes to these two settings, but can anyone
confirm that i am headed in the right direction? Or any other pointers on this?
> On Sun, Feb 26, 2012 at 5:26 PM, Mohit Anchlia <> wrote:
> On Sun, Feb 26, 2012 at 12:18 PM, aaron morton <> wrote:
> Nathan Milford has a post about taking a node down 
> The only thing I would do differently would be turn off thrift first.
> Cheers
> Isn't decomission meant to do the same thing as disablethrift and gossip?
> -----------------
> Aaron Morton
> Freelance Developer
> @aaronmorton
> On 27/02/2012, at 4:35 AM, Edward Capriolo wrote:
>> If you are doing a planned maintenance you can flush first as well
>> ensuring the that the commit logs will not be as large.
>> On Sun, Feb 26, 2012 at 10:09 AM, Radim Kolar <> wrote:
>>>> if a node goes down, it will take longer for commitlog replay.
>>> commit log replay time is insignificant. most time during node startup is
>>> wasted on index sampling. Index sampling here runs for about 15 minutes.

View raw message