Hi, I sympathize with your issue. I recommend adding the following to your JVM flags:
JVM_OPTS="$JVM_OPTS -XX:+PrintGCDetails" JVM_OPTS="$JVM_OPTS -XX:+PrintGCDateStamps" JVM_OPTS="$JVM_OPTS -XX:+PrintHeapAtGC" JVM_OPTS="$JVM_OPTS -XX:+PrintTenuringDistribution" JVM_OPTS="$JVM_OPTS -XX:+PrintGCApplicationStoppedTime" JVM_OPTS="$JVM_OPTS -XX:+PrintPromotionFailure" JVM_OPTS="$JVM_OPTS -XX:PrintFLSStatistics=1" JVM_OPTS="$JVM_OPTS -XX:+PrintSafepointStatistics" JVM_OPTS="$JVM_OPTS -XX:+PrintClassHistogramBeforeFullGC" JVM_OPTS="$JVM_OPTS -XX:+PrintClassHistogramAfterFullGC" Provide the compaction settings from your schema and cassandra.yaml. Also try rolling back the JVM config to the defaults shipped with C*. I recall G1 was not recommended for Cassandra. Change back SurvivorRatio to 8 and remove NewRatio. Next time you got long GCs, try to find segment of gc.log the relates to the long pause. You can do that by greping the log for keyword "stopped". Paste anything above it. From there, I can help you explore a few things: 1. Compaction Pressure; 2. Potentially reading a fat row; (> 10Mb) 3. Premature tenuring of objects in Java heap. Cheers, -Arya On Tue, Jan 14, 2014 at 5:39 AM, Dimetrio <dimet...@flysoft.ru> wrote: > iostat is clean > vm.max_map_count = 131072 > > > > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Cassandra-mad-GC-tp7592248p7592251.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. > -- Cheers, -Arya
