You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Brian Burruss <bb...@real.com> on 2009/12/08 01:59:58 UTC

exception during startup

wanted to pass this along ... i have 2G RAM allocated to cassandra.  should it need more?  what are the factors that determine the amount of memory required?

thx!

2009-12-07 16:56:30,787 ERROR [main] [CassandraDaemon.java:184] Exception encountered during startup.
java.lang.OutOfMemoryError: Java heap space
	at org.apache.cassandra.db.CommitLog.recover(CommitLog.java:317)
	at org.apache.cassandra.db.RecoveryManager.doRecovery(RecoveryManager.java:65)
	at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:90)
	at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:166)

RE: exception during startup

Posted by Brian Burruss <bb...@real.com>.
i applied both patches and restarted cassandra.  all seems well.  memory stayed lower, but i'm not sure if this is because cassandra didn't have as many commit logs to replay or not as the data has changed since my initial Exception.

thx
________________________________________
From: Jonathan Ellis [jbellis@gmail.com]
Sent: Monday, December 07, 2009 6:34 PM
To: cassandra-user@incubator.apache.org
Subject: Re: exception during startup

Patch attached to the jira issue.  Please give it a try if you are
running trunk or the 0.5 beta.  If this is data you care about, you
should make a copy of the commitlog files, just in case. :)

On Mon, Dec 7, 2009 at 8:11 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> on log replay, cassandra cheats and puts all the changes into memory
> before writing to disk, bypassing the normal "is this memtable full
> yet" checks.  this is an optimization but IMO it's misguided because
> it can lead to OOM on replay when you wouldn't OOM for the same set of
> changes during normal operation.
>
> I've created https://issues.apache.org/jira/browse/CASSANDRA-609 to
> fix this, but the fix may be a little involved, so if you can
> temporarily give Cassandra more memory to finish the replay, that is
> the easiest workaround and you can set it back the way it was once
> replay completes successfully.
>
> On Mon, Dec 7, 2009 at 6:59 PM, Brian Burruss <bb...@real.com> wrote:
>> wanted to pass this along ... i have 2G RAM allocated to cassandra.  should it need more?  what are the factors that determine the amount of memory required?
>>
>> thx!
>>
>> 2009-12-07 16:56:30,787 ERROR [main] [CassandraDaemon.java:184] Exception encountered during startup.
>> java.lang.OutOfMemoryError: Java heap space
>>        at org.apache.cassandra.db.CommitLog.recover(CommitLog.java:317)
>>        at org.apache.cassandra.db.RecoveryManager.doRecovery(RecoveryManager.java:65)
>>        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:90)
>>        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:166)
>>
>

Re: exception during startup

Posted by Jonathan Ellis <jb...@gmail.com>.
Patch attached to the jira issue.  Please give it a try if you are
running trunk or the 0.5 beta.  If this is data you care about, you
should make a copy of the commitlog files, just in case. :)

On Mon, Dec 7, 2009 at 8:11 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> on log replay, cassandra cheats and puts all the changes into memory
> before writing to disk, bypassing the normal "is this memtable full
> yet" checks.  this is an optimization but IMO it's misguided because
> it can lead to OOM on replay when you wouldn't OOM for the same set of
> changes during normal operation.
>
> I've created https://issues.apache.org/jira/browse/CASSANDRA-609 to
> fix this, but the fix may be a little involved, so if you can
> temporarily give Cassandra more memory to finish the replay, that is
> the easiest workaround and you can set it back the way it was once
> replay completes successfully.
>
> On Mon, Dec 7, 2009 at 6:59 PM, Brian Burruss <bb...@real.com> wrote:
>> wanted to pass this along ... i have 2G RAM allocated to cassandra.  should it need more?  what are the factors that determine the amount of memory required?
>>
>> thx!
>>
>> 2009-12-07 16:56:30,787 ERROR [main] [CassandraDaemon.java:184] Exception encountered during startup.
>> java.lang.OutOfMemoryError: Java heap space
>>        at org.apache.cassandra.db.CommitLog.recover(CommitLog.java:317)
>>        at org.apache.cassandra.db.RecoveryManager.doRecovery(RecoveryManager.java:65)
>>        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:90)
>>        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:166)
>>
>

Re: exception during startup

Posted by Jonathan Ellis <jb...@gmail.com>.
on log replay, cassandra cheats and puts all the changes into memory
before writing to disk, bypassing the normal "is this memtable full
yet" checks.  this is an optimization but IMO it's misguided because
it can lead to OOM on replay when you wouldn't OOM for the same set of
changes during normal operation.

I've created https://issues.apache.org/jira/browse/CASSANDRA-609 to
fix this, but the fix may be a little involved, so if you can
temporarily give Cassandra more memory to finish the replay, that is
the easiest workaround and you can set it back the way it was once
replay completes successfully.

On Mon, Dec 7, 2009 at 6:59 PM, Brian Burruss <bb...@real.com> wrote:
> wanted to pass this along ... i have 2G RAM allocated to cassandra.  should it need more?  what are the factors that determine the amount of memory required?
>
> thx!
>
> 2009-12-07 16:56:30,787 ERROR [main] [CassandraDaemon.java:184] Exception encountered during startup.
> java.lang.OutOfMemoryError: Java heap space
>        at org.apache.cassandra.db.CommitLog.recover(CommitLog.java:317)
>        at org.apache.cassandra.db.RecoveryManager.doRecovery(RecoveryManager.java:65)
>        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:90)
>        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:166)
>