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 other bottlenecks would be good, too. By the
way, it is always good to list what JVM you're using. }

On Mon, Apr 19, 2010 at 8:18 PM, Schubert Zhang <zson...@gmail.com> wrote:

> 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:TargetSurvivorRatio=90 \
>         -XX:+AggressiveOpts \
>         -XX:+UseParNewGC \
>         -XX:+UseConcMarkSweepGC \
>         -XX:+CMSParallelRemarkEnabled \
>         -XX:SurvivorRatio=128 \
>         -XX:MaxTenuringThreshold=0 \
>         -Dcom.sun.management.jmxremote.port=8081 \
>         -Dcom.sun.management.jmxremote.ssl=false \
>         -Dcom.sun.management.jmxremote.authenticate=false"
>
>
> On Tue, Apr 20, 2010 at 5:46 AM, Masood Mortazavi <
> masoodmortaz...@gmail.com> wrote:
>
>> 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, using the GC logs, one can investigate further. There may
>> be places were some object recycling can make some larger difference.
>> Trying this first will probably bear more immediate fruit.
>>
>> - m.
>>
>>
>> On Mon, Apr 19, 2010 at 9:11 AM, Daniel Kluesing <d...@bluekai.com> wrote:
>>
>>>  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:15 AM
>>> *To:* user@cassandra.apache.org; d...@cassandra.apache.org
>>> *Subject:* 0.6 insert performance .... Re: [RELEASE] 0.6.1
>>>
>>>
>>>
>>> I wonder if anyone can use:
>>>
>>>  * Add logging of GC activity (CASSANDRA-813)
>>> to confirm this:
>>>
>>> http://www.slideshare.net/schubertzhang/cassandra-060-insert-throughput
>>>
>>> - m.
>>>
>>>  On Sun, Apr 18, 2010 at 6:58 PM, Eric Evans <eev...@rackspace.com>
>>> wrote:
>>>
>>>
>>> Hot on the trails of 0.6.0 comes our latest, 0.6.1. This stable point
>>> release contains a number of important bugfixes[1] and is a painless
>>> upgrade from 0.6.0.
>>>
>>> Enjoy!
>>>
>>> [1]: http://bit.ly/9NqwAb (changelog)
>>>
>>> --
>>> Eric Evans
>>> eev...@rackspace.com
>>>
>>>
>>>
>>
>>
>

Reply via email to