Typically nothing is ever logged other than the GC failures
In addition to the heapdumps,
be useful to see some GC logs
(turn on GC logs via cassandra.in.sh
Or add
-Xloggc:/var/log/cassandra/gc.log
-XX:+PrintGCDetails
)
thanks, Sri
On May 7, 2011, at 6:37 PM, Jonathan Ellis
Out of curiosity, could you try to disable mmap as well?
I had some problems here some time back and I wanted to see better what was
going on and disabled the mmap.
I actually don't think I have the same problem again, but I have seen javavm
sizes up in 30-40MB with a heap of just 16.
Haven't
Hi Adam,
We have been facing some similar issues of late. Wondering if Jonathan's
suggestions worked for you.
Thanks!
On Sat, May 7, 2011 at 6:37 PM, Jonathan Ellis jbel...@gmail.com wrote:
The live:serialized size ratio depends on what your data looks like
(small columns will be less
How much memory should a single hot cf with a 128mb memtable take with row and
key caching disabled during read?
Because I'm seeing heap go from 3.5gb skyrocketing straight to max (regardless
of the size, 8gb and 24gb both do the same) at which time the jvm will do
nothing but full gc and is
The live:serialized size ratio depends on what your data looks like
(small columns will be less efficient than large blobs) but using the
rule of thumb of 10x, around 1G * (1 + memtable_flush_writers +
memtable_flush_queue_size).
So first thing I would do is drop writers and queue to 1 and 1.
We're troubleshooting a memory usage problem during batch reads. We've spent
the last few days profiling and trying different GC settings. The symptoms are
that after a certain amount of time during reads one or more nodes in the
cluster will exhibit extreme memory pressure followed by a gc
You don't GC storm without legitimately having a too-full heap. It's
normal to see occasional full GCs from fragmentation, but that will
actually compact the heap and everything goes back to normal IF you
had space actually freed up.
You say you've played w/ memtable size but that would still be
