Didn't have time yet to properly respond to this one, but check out
the Very high memory utilization (not caused by mmap on sstables)
thread from today. You're using the same Ubuntu/JVM, right? Seems to
match your observations.
(Sorry no ML archive link; the ML archives for Apache projects has
Hi Peter,
I've read through the Very high memory utilization (not caused by mmap
on sstables) and the impact sounds similar .. alas they're using openJDK
and I'm using Sun's. Of course, it's not impossible that the same bug is
present in both JVM's.
j.
This bug is present in both Sun JDK and open JDK because they share the same
hotspot VM. Sun JDK got the fix earlier than open JDK.
best regards,
hanzhu
On Thu, Dec 16, 2010 at 6:43 PM, Jedd Rashbrooke
jedd.rashbro...@imagini.net wrote:
Hi Peter,
I've read through the Very high memory
Hey Peter,
On 14 December 2010 20:19, Peter Schuller peter.schul...@infidyne.com wrote:
So, now that I get that we have two different cases ;)
Yup. My problem is java / environment based, occurring
after several weeks, using 0.6.6 instances. Our thread
hijacking friend / learned
Peter, Jonathon - thank you for your replies.
I should probably have repeated myself in the body, but as I
mentioned in the subject line, we're running Sun Java 1.6.
On 10 December 2010 18:37, Peter Schuller peter.schul...@infidyne.com wrote:
Memory-mapped files will account for both
On Dec 12, 2010, at 17:21, Jonathan Ellis wrote:
http://www.riptano.com/docs/0.6/troubleshooting/index#nodes-are-dying-with-oom-errors
I can rule out the first 3. I was running cassandra with default settings, i.e.
1GB heap and 256M memtable. So, with 3 memtables+1GB the JVM should run with
On Tue, 2010-12-14 at 11:06 +, Jedd Rashbrooke wrote:
JNA is something I'd read briefly about a while back, but now
it might be something I need to explore further. We're using
Cassandra 0.6.6, and our Ubuntu version offers a packaged
release of libjna 3.2.3-1 .. rumours on the
On Dec 14, 2010, at 15:31, Timo Nentwig wrote:
On Dec 14, 2010, at 14:41, Jonathan Ellis wrote:
This is A row has grown too large section from that troubleshooting guide.
Why? This is what a typical row (?) looks like:
[defa...@test] list tracking limit 1;
---
RowKey:
Memory-mapped files will account for both virtual and, to the extent
that they are resident in memory, to the resident size of the process.
This bears further investigation. Would you consider a 3GB overhead
on a 4GB heap a possibility? (From a position of some naivety, this
seems a bit
I can rule out the first 3. I was running cassandra with default settings,
i.e. 1GB heap and 256M memtable. So, with 3 memtables+1GB the JVM should run
with 1.75G (although http://wiki.apache.org/cassandra/MemtableThresholds
considers to increase heap size only gently). Did so. 4GB machine
java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.init(HeapByteBuffer.java:39)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
at
org.apache.cassandra.utils.FBUtilities.readByteArray(FBUtilities.java:261)
at
On Dec 14, 2010, at 19:38, Peter Schuller wrote:
For debugging purposes you may want to switch Cassandra to standard
IO mode instead of mmap. This will have a performance-penalty, but the
virtual/resident sizes won't be polluted with mmap():ed data.
Already did so. It *seems* to run more
The stack trace doesn't make sense relative to what I get checking out
0.6.6. Are you *sure* this is 0.6.6, without patches or other changes?
Oh, sorry, the original poster of this thread was/is actually using 0.6, I am
(as mentioned in other posts) actually on 0.7rc2. Sorry that I didn't
I just uncommented the GC JVMOPTS from the shipped cassandra start script and
use Sun JVM 1.6.0_23. Hmm, but these GC tuning options are also
uncommented. I'll comment them again and try again.
Maybe I was just too quick trying to mentally parse it and given the
jumbled line endings. You're
For debugging purposes you may want to switch Cassandra to standard
IO mode instead of mmap. This will have a performance-penalty, but the
virtual/resident sizes won't be polluted with mmap():ed data.
Already did so. It *seems* to run more stable, but it's still far off from
being stable.
I posted mostly as a heads up for others using similar profiles (4GB
heap on ~8GB boxes) to keep an eye out for. I expect a few people,
particularly if they're on Amazon EC2, are running this type of setup.
On the other hand, mum always said I was unique. ;)
So, now that I get that we
If it helps, I also found quite a few of these in the logs
org.apache.cassandra.db.UnserializableColumnFamilyException: Couldn't find
cfId=224101
However a single cassandra instance locally (OSX, 1.6.0_22, mmap) runs just
perfect for
hours. No exceptions, no OOM.
Given that these
On Dec 10, 2010, at 19:37, Peter Schuller wrote:
To cargo cult it: Are you running a modern JVM? (Not e.g. openjdk b17
in lenny or some such.) If it is a JVM issue, ensuring you're using a
reasonably recent JVM is probably much easier than to start tracking
it down...
I had OOM problems
http://www.riptano.com/docs/0.6/troubleshooting/index#nodes-are-dying-with-oom-errors
On Sun, Dec 12, 2010 at 9:52 AM, Timo Nentwig timo.nent...@toptarif.dewrote:
On Dec 10, 2010, at 19:37, Peter Schuller wrote:
To cargo cult it: Are you running a modern JVM? (Not e.g. openjdk b17
in
Over the past month or so, it looks like memory has slowly
been exhausted. Both nodetool drain and jmap can't run, and
produce this error:
Error occurred during initialization of VM
Could not reserve enough space for object heap
We've got Xmx/Xms set to 4GB.
top shows free
20 matches
Mail list logo
