I finally upgraded to 0.7.4 -> 0.8.0 (using riptano packages) 2 days ago. Before, my resident memory (for the java process) would slowly grow without bound and the OS would kill the process. But, over the last 2 days, I _think_ it's been stable. I'll let you know in a week :-)
My other stats: AWS large (64 bit, 7.5GB, 4 "compute units", no swap by default and I didn't enable it manually) Centos 5.6 Sun 1.6.0_24-b07 2 column families 4 machine cluster with RF=3 Mostly balanced write/read load (usually more writes) Not quite "big data" volumes, large 10^6 or small 10^7 ops/day No deletes or mutations, I only add or read Everything else is stock, I haven't tuned anything as performance was ok. No JVM options other than what was in the package. No JNA. Not sure the GC patterns. will On Tue, Jul 12, 2011 at 9:28 AM, Chris Burroughs <chris.burrou...@gmail.com>wrote: > ### Preamble > > There have been several reports on the mailing list of the JVM running > Cassandra using "too much" memory. That is, the resident set size is > >>(max java heap size + mmaped segments) and continues to grow until the > process swaps, kernel oom killer comes along, or performance just > degrades too far due to the lack of space for the page cache. It has > been unclear from these reports if there is a pattern. My hope here is > that by comparing JVM versions, OS versions, JVM configuration etc., we > will find something. Thank you everyone for your time. > > > Some example reports: > - http://www.mail-archive.com/user@cassandra.apache.org/msg09279.html > - > > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Very-high-memory-utilization-not-caused-by-mmap-on-sstables-td5840777.html > - https://issues.apache.org/jira/browse/CASSANDRA-2868 > - > > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/OOM-or-what-settings-to-use-on-AWS-large-td6504060.html > - > > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Cassandra-memory-problem-td6545642.html > > For reference theories include (in no particular order): > - memory fragmentation > - JVM bug > - OS/glibc bug > - direct memory > - swap induced fragmentation > - some other bad interaction of cassandra/jdk/jvm/os/nio-insanity. > > ### Survey > > 1. Do you think you are experiencing this problem? > > 2. Why? (This is a good time to share a graph like > http://www.twitpic.com/5fdabn or > http://img24.imageshack.us/img24/1754/cassandrarss.png) > > 2. Are you using mmap? (If yes be sure to have read > http://wiki.apache.org/cassandra/FAQ#mmap , and explain how you have > used pmap [or another tool] to rule you mmap and top decieving you.) > > 3. Are you using JNA? Was mlockall succesful (it's in the logs on > startup)? > > 4. Is swap enabled? Are you swapping? > > 5. What version of Apache Cassandra are you using? > > 6. What is the earliest version of Apache Cassandra you recall seeing > this problem with? > > 7. Have you tried the patch from CASSANDRA-2654 ? > > 8. What jvm and version are you using? > > 9. What OS and version are you using? > > 10. What are your jvm flags? > > 11. Have you tried limiting direct memory (-XX:MaxDirectMemorySize) > > 12. Can you characterise how much GC your cluster is doing? > > 13. Approximately how many read/writes per unit time is your cluster > doing (per node or the whole cluster)? > > 14. How are you column families configured (key cache size, row cache > size, etc.)? > >
