Look at the OOM section in
http://www.datastax.com/docs/0.6/troubleshooting/index
On Fri, Oct 7, 2011 at 3:47 AM, Stefan Reek wrote:
> Is it actually filling up enough to trigger an old-gen CMS gc?
>
>
> Yes, it fills up to the 16G and then it starts doing the CMS gc's which
> dramatically decrea
Is it actually filling up enough to trigger an old-gen CMS gc?
Yes, it fills up to the 16G and then it starts doing the CMS gc's which
dramatically decreases the performance.
I'm still not sure why it does this, as a nodetool info states the load
as less than 4G.
Any ideas?
On 10/06/2011 06
On Thu, Oct 6, 2011 at 10:53 AM, Stefan Reek wrote:
> We do have the commitlogs on separate devices, are there any other basics
> that I could have forgotten, or
> any parameters that are important for write performance?
1.0 write performance is something like 30% better... I don't think
there's
On 10/06/2011 05:26 PM, Jonathan Ellis wrote:
On Thu, Oct 6, 2011 at 10:09 AM, Stefan Reek wrote:
I can see that during the times the writing gets slow there are ~3000
pending tasks, but they disappear quickly.
Your best bet is to make the write load more constant and less bursty.
On Thu, Oct 6, 2011 at 10:09 AM, Stefan Reek wrote:
> I can see that during the times the writing gets slow there are ~3000
> pending tasks, but they disappear quickly.
Your best bet is to make the write load more constant and less bursty.
If you really do need to handle bursts like that with lo
Hi guys,
We're currently testing an application against a very high load, which
runs against Cassandra 0.6.13 (I know, we just never got the time to
upgrade).
The nature of our app is that it will write to two different
SuperColumnFamilies in bursts, and to some other columnfamilies less
frequent
