cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Persistently increasing read latency
Date Wed, 02 Dec 2009 18:32:15 GMT
We are using trunk.  0.5 beta / trunk is better than 0.4 at the 0.4
functionality and IMO is production ready (although you should always
test first), but I would not yet rely on the new stuff (bootstrap,
loadbalance, and moving nodes around in general).

-Jonathan

On Wed, Dec 2, 2009 at 12:26 PM, Adam Fisk <a@littleshoot.org> wrote:
> Helpful thread guys. In general, Jonathan, would you recommend
> building from trunk for new deployments at our current snapshot in
> time? Are you using trunk at Rackspace?
>
> Thanks.
>
> -Adam
>
>
> On Tue, Dec 1, 2009 at 6:18 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
>> On Tue, Dec 1, 2009 at 7:31 PM, Freeman, Tim <tim.freeman@hp.com> wrote:
>>> Looking at the Cassandra mbean's, the attributes of ROW-MUTATION-STAGE and ROW-READ-STAGE
and RESPONSE-STAGE are all  less than 10.  MINOR-COMPACTION-POOL reports 1218 pending tasks.
>>
>> That's probably the culprit right there.  Something is wrong if you
>> have 1200 pending compactions.
>>
>> This is something that upgrading to trunk will help with right away
>> since we parallelize compactions there.
>>
>> Another thing you can do is increase the memtable limits so you are
>> not flushing + compacting so often with your insert traffic.
>>
>> -Jonathan
>>
>
>
>
> --
> Adam Fisk
> http://www.littleshoot.org | http://adamfisk.wordpress.com |
> http://twitter.com/adamfisk
>

Mime
View raw message