cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xaero S <xaeros...@gmail.com>
Subject Re: Frequency of Flushing in 1.0
Date Wed, 29 Feb 2012 00:10:24 GMT
Thank you Aaron and others.
That helped and we were able to limit the commitlog disk usage.
We will be doing some tests by changing the memtable_total_space_in_mb
param and see how that goes.

On Mon, Feb 27, 2012 at 12:51 PM, aaron morton <aaron@thelastpickle.com>wrote:

> yes, reducing commitlog_total_space_in_mb will reduce the amount of space
> needed by the commit logs.
>
> 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
> @aaronmorton
> http://www.thelastpickle.com
>
> 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 -
> http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-memory-and-disk-space-management,
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 <mohitanchlia@gmail.com>wrote:
>
>>
>>
>> On Sun, Feb 26, 2012 at 12:18 PM, aaron morton <aaron@thelastpickle.com>wrote:
>>
>>> Nathan Milford has a post about taking a node down
>>>
>>> http://blog.milford.io/2011/11/rolling-upgrades-for-cassandra/
>>>
>>> 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
>>> http://www.thelastpickle.com
>>>
>>>  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 <hsn@sendmail.cz> 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.
>>>
>>>
>>>
>>
>
>

Mime
View raw message