You're welcome Schubert.
I look forward to any new results you may come up with.
{ It would also be interesting, when you run your tests again, to look at
the GC logs and see to what extent
https://issues.apache.org/jira/browse/CASSANDRA-896 is the culprit for what
you will see. Identifying any ot
Since the scale of GC graph in the slides is different from the throughput
ones. I will do another test for this issue.
Thanks for your advices, Masood and Jonathan.
---
Here, i just post my cossandra.in.sh.
JVM_OPTS=" \
-ea \
-Xms128M \
-Xmx6G \
-XX:Tar
Definitely let us know if you find that changing the GC options helps.
We have tried to get some of the low-hanging fruit there but nobody
has put serious effort into tuning it.
FWIW, Chris Goffinet tested using ArrayBlockingQueue instead of LBQ in
https://issues.apache.org/jira/browse/CASSANDRA-
Minimizing GC pauses or minimizing time slots allocated to GC pauses --
either through configuration or re-implementations of garbage collection
"bottlenecks" (i.e. object-generation "bottlenecks") -- seem to be the
immediate approach. (Other approaches appear to be more intrusive.)
At code level,
We see this behavior as well with 0.6, heap usage graphs look almost identical.
The GC is a noticeable bottleneck, we've tried jdku19 and jrockit vm's. It
basically kills any kind of soft real time behavior.
From: Masood Mortazavi [mailto:masoodmortaz...@gmail.com]
Sent: Monday, April 19, 2010 4
