You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Masood Mortazavi <ma...@gmail.com> on 2010/04/19 13:14:47 UTC
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 <ee...@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
> eevans@rackspace.com
>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Jonathan Ellis <jb...@gmail.com>.
It's hard to tell from those slides, but it looks like the slowdown
doesn't hit until after several GCs.
Perhaps this is compaction kicking in, not GCs? Definitely the extra
I/O + CPU load from compaction will cause a drop in throughput.
On Mon, Apr 19, 2010 at 6:14 AM, Masood Mortazavi
<ma...@gmail.com> wrote:
> 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 <ee...@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
>> eevans@rackspace.com
>>
>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Masood Mortazavi <ma...@gmail.com>.
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 <zs...@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 <
> masoodmortazavi@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 <dk...@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:masoodmortazavi@gmail.com]
>>> *Sent:* Monday, April 19, 2010 4:15 AM
>>> *To:* user@cassandra.apache.org; dev@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 <ee...@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
>>> eevans@rackspace.com
>>>
>>>
>>>
>>
>>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Masood Mortazavi <ma...@gmail.com>.
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 <zs...@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 <
> masoodmortazavi@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 <dk...@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:masoodmortazavi@gmail.com]
>>> *Sent:* Monday, April 19, 2010 4:15 AM
>>> *To:* user@cassandra.apache.org; dev@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 <ee...@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
>>> eevans@rackspace.com
>>>
>>>
>>>
>>
>>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Schubert Zhang <zs...@gmail.com>.
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 <masoodmortazavi@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 <dk...@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:masoodmortazavi@gmail.com]
>> *Sent:* Monday, April 19, 2010 4:15 AM
>> *To:* user@cassandra.apache.org; dev@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 <ee...@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
>> eevans@rackspace.com
>>
>>
>>
>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Schubert Zhang <zs...@gmail.com>.
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 <masoodmortazavi@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 <dk...@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:masoodmortazavi@gmail.com]
>> *Sent:* Monday, April 19, 2010 4:15 AM
>> *To:* user@cassandra.apache.org; dev@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 <ee...@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
>> eevans@rackspace.com
>>
>>
>>
>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Jonathan Ellis <jb...@gmail.com>.
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-896 but the higher
contention outweighed the benefits of creating less garbage.
-Jonathan
On Mon, Apr 19, 2010 at 4:46 PM, Masood Mortazavi
<ma...@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 <dk...@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:masoodmortazavi@gmail.com]
>> *Sent:* Monday, April 19, 2010 4:15 AM
>> *To:* user@cassandra.apache.org; dev@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 <ee...@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
>> eevans@rackspace.com
>>
>>
>>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Masood Mortazavi <ma...@gmail.com>.
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 <dk...@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:masoodmortazavi@gmail.com]
> *Sent:* Monday, April 19, 2010 4:15 AM
> *To:* user@cassandra.apache.org; dev@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 <ee...@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
> eevans@rackspace.com
>
>
>
Re: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Masood Mortazavi <ma...@gmail.com>.
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 <dk...@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:masoodmortazavi@gmail.com]
> *Sent:* Monday, April 19, 2010 4:15 AM
> *To:* user@cassandra.apache.org; dev@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 <ee...@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
> eevans@rackspace.com
>
>
>
RE: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Daniel Kluesing <dk...@bluekai.com>.
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:masoodmortazavi@gmail.com]
Sent: Monday, April 19, 2010 4:15 AM
To: user@cassandra.apache.org; dev@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 <ee...@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
eevans@rackspace.com<ma...@rackspace.com>
RE: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Daniel Kluesing <dk...@bluekai.com>.
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:masoodmortazavi@gmail.com]
Sent: Monday, April 19, 2010 4:15 AM
To: user@cassandra.apache.org; dev@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 <ee...@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
eevans@rackspace.com<ma...@rackspace.com>
RE: 0.6 insert performance .... Re: [RELEASE] 0.6.1
Posted by Mark Jones <MJ...@imagehawk.com>.
I'm seeing some issues like this as well, in fact, I think seeing your graphs has helped me understand the dynamics of my cluster better.
Using some ballpark figures for inserting single column objects of ~500 bytes onto individual nodes(not when combined as a cluster):
Node1: Inserts 12000/s
Node2: Inserts 12000/s
Node3: Inserts 9000/s
Node4: Inserts 6000/s
When combined as a cluster, inserts are around 7000/s (replication factor of 2)
When GC kicks in anywhere in the cluster, Quorum writes slowdown for everyone associated with that node. And the fact that there are 4 Nodes, almost implies garbage collection will be going on somewhere almost all the time.
So while I should be able to write more than 12,000/second, my slowest node in the cluster seems to overwhelm the faster nodes and drag everyone down. I'm still running tests of various combinations to see where things work out.
From: Masood Mortazavi [mailto:masoodmortazavi@gmail.com]
Sent: Monday, April 19, 2010 6:15 AM
To: user@cassandra.apache.org; dev@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 <ee...@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
eevans@rackspace.com<ma...@rackspace.com>