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 aa...@thelastpickle.comwrote:
yes, reducing
Isn't decomission meant to do the same thing as disablethrift and gossip?
decommission removes a node entirely from the cluster, including streaming it's
data to other nodes.
disablethrift and disablegossip just stop it from responding to clients and
other nodes.
Cheers
-
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
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.
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 h...@sendmail.cz wrote:
if a node goes down, it will take longer for commitlog replay.
commit log replay time is
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
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On
On Sun, Feb 26, 2012 at 12:18 PM, aaron morton aa...@thelastpickle.comwrote:
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
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.
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.
Depends entirely on your situation. If you have few keys and lots of
writes, index
http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-memory-and-disk-space-management
On Thu, Feb 23, 2012 at 6:05 PM, Xaero S xaeros...@gmail.com wrote:
I recently started using Cassandra 1.0.4 and observed that it takes a lot
longer to flush the commit logs to SSTables, than
I recently started using Cassandra 1.0.4 and observed that it takes a lot
longer to flush the commit logs to SSTables, than was observed in versions
0.7.X and 0.8.X under constant load conditions with commitlog_sync as
periodic and commitlog_sync_period_in_ms as 1. As more data gets
retained
11 matches
Mail list logo
