I've started seeing this issue as well. Running 0.6.2. One interesting thing I happened upon, I explicitly called the GC via jconsole and the heap dropped completely fixing the issue. When you explicitly call System.gc() it does a full sweep. I'm wondering if this issue is to do with the GC flags used.
-Jake On Wed, Jun 2, 2010 at 3:09 PM, Torsten Curdt <tcu...@vafer.org> wrote: > We've also seen something like this. Will soon investigate and try > again with 0.6.2 > > On Wed, Jun 2, 2010 at 20:27, Paul Brown <paulrbr...@gmail.com> wrote: > > > > FWIW, I'm seeing similar issues on a cluster. Three nodes, Cassandra > 0.6.1, SUN JDK 1.6.0_b20. I will try to get some heap dumps to see what's > building up. > > > > I've seen this sort of issue in systems that make heavy use of > java.util.concurrent queues/executors, e.g.: > > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6236036 > > > > That bug is long fixed, but it is an instance of how it can be harder to > do nothing than something. > > > > -- Paul > > > > > > On May 26, 2010, at 11:32 PM, James Golick wrote: > > > >> We're seeing RAM usage continually climb until eventually, cassandra > becomes unresponsive. > >> > >> The JVM isn't OOM'ing. It has only committed 14/24GB of memory. So, I am > assuming that the memory usage is related to mmap'd IO. Fair assumption? > >> > >> I tried setting the IO mode to standard, but it seemed to be a little > slower and couldn't get the machine to come back online with adequate read > performance, so I set it back. I'll have to write a solid cache warming > script if I'm going to try that again. > >> > >> Any other ideas for what might be causing the issue? Is there something > I should monitor or look at next time it happens? > >> > >> Thanks > > > > >
