incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <peter.schul...@infidyne.com>
Subject Re: 0.7 memory usage problem
Date Sat, 25 Sep 2010 16:58:20 GMT
> My rows consist of only 60 columns and these 60 columns looks like this:
> ColumnName: Sensor59 -- Value: 434.2647915698039 -- TTL: 10800

The hotspot error log indicates the OOM is actually the result of a
*stack* overflow rather than a heap overflow. While the first OOM in
system.log indicates it's compaction, the stack frame claimed to be
the culprit in the hotspot error log is different and actually occurs
in the read path.

I'm pretty surprised since I don't believe there is anything extreme
going on in terms of Java level stack depth, and it seems unexpected
to me that any of the native I/O code would be doing unbounded stack
allocation. VM args don't contain custom -Xss according to the hotspot
error log.

I would say "try a newer JVM", except you seem to be on the latest 1.6 update.

In a recent openjdk7, RandomAccessFile.readBytes() ends up in
readBytes() in share/native/java/io/io_util.c which only uses stack
allocations for reads <= 8192 bytes. I didn't check earlier JDK:s but
it seems highly unlikely that such a core feature would do unbounded
stack allocation and have it go unnoticed. Neither does it sound
likely that the default stack size on Windows is so small as to make
this an expected outcome given the stack depth in Cassandra.

I wonder if there is memory corruption going on that causes the
overflow. Or am I missing something simple?

-- 
/ Peter Schuller

Mime
View raw message