cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Large commit log reasons
Date Wed, 23 Jan 2013 15:59:16 GMT
By default Cassandra uses 1/3rd heap size for memtable storage. If you make
sure memtables smaller they should flush faster and you commit logs should
not grow large.

Large commit logs are not a problem, some use cases that write to some
Column Families more then other can make the commit log directory grow.
Basically the commit log does not get removed until everything in it is
flushed. We have a nagios alarm on ours, if it hits 8GB something is wrong,
but again large commit log is normal and I would not worry.

Edward

On Wed, Jan 23, 2013 at 10:42 AM, vhmolinar <vhmolinar@gmail.com> wrote:

> Hi fellows.
> I current have 3 nodes cluster running with a replication factor of 1.
> It's a pretty simple deployment and all my enforcements are focused in
> writes rather than reads.
> Actually I'm noticing that my commit log size is always very big if
> compared
> to the ammout of data being persisted(which varies on 5gb).
>
> So, that lead me to three doubts:
> 1- When a commit log gets bigger, does it mean that cassandra hasnt
> processed yet those writes?
> 2- How could I speed my flushes to sstables?
> 3- Does my commit log decrease as much as my sstable increases? Is it a
> rule?
>
>
>
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Large-commit-log-reasons-tp7584964.html
> Sent from the cassandra-user@incubator.apache.org mailing list archive at
> Nabble.com.
>

Mime
View raw message