Agreed need more details; and just start by increasing heap because that may wells solve the problem.
I have just observed (which makes sense when you think about it) while testing fix for https://issues.apache.org/jira/browse/CASSANDRA-7546, that if you are replaying a commit log which has a high level of updates for the same partition key, you can hit that issue - excess memory allocation under high contention for the same partition key - (this might not cause OOM but will certainly massively tax GC and it sounds like you don’t have a lot/any headroom). On Aug 12, 2014, at 12:31 PM, Robert Coli <rc...@eventbrite.com> wrote: > > On Tue, Aug 12, 2014 at 9:34 AM, jivko donev <jivko_...@yahoo.com> wrote: > We have a node with commit log director ~4G. During start-up of the node on > commit log replaying the used heap space is constantly growing ending with > OOM error. > > The heap size and new heap size properties are - 1G and 256M. We are using > the default settings for commitlog_sync, commitlog_sync_period_in_ms and > commitlog_segment_size_in_mb. > > What version of Cassandra? > > 1G is tiny for cassandra heap. There is a direct relationship between the > data in the commitlog and memtables and in the heap. You almost certainly > need more heap or less commitlog. > > =Rob >
smime.p7s
Description: S/MIME cryptographic signature
