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 <[email protected]> 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) >
