incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Danforth <>
Subject Re: Replicate On Write behavior
Date Fri, 02 Sep 2011 17:18:13 GMT
That ticket explains a lot, looking forward to a resolution on it.
(Sorry I don't have a patch to offer)


On Fri, Sep 2, 2011 at 12:30 AM, Sylvain Lebresne <> wrote:
> On Thu, Sep 1, 2011 at 8:52 PM, David Hawthorne <> wrote:
>> I'm curious... digging through the source, it looks like replicate on write triggers
a read of the entire row, and not just the columns/supercolumns that are affected by the counter
update.  Is this the case?  It would certainly explain why my inserts/sec decay over time
and why the average insert latency increases over time.  The strange thing is that I'm not
seeing disk read IO increase over that same period, but that might be due to the OS buffer
> It does not. It only reads the columns/supercolumns affected by the
> counter update.
> In the source, this happens in If you look at
> addReadCommandFromColumnFamily you'll see that it does a query by name
> only for the column involved in the update (the update is basically
> the content of the columnFamily parameter there).
> And Cassandra does *not* always reads a full row. Never had, never will.
>> On another note, on a 5-node cluster, I'm only seeing 3 nodes with ReplicateOnWrite
Completed tasks in nodetool tpstats output.  Is that normal?  I'm using RandomPartitioner...
>> Address         DC          Rack        Status State   Load      
     Owns    Token
>>    datacenter1 rack1       Up     Normal  2.26 GB         20.00%
>>    datacenter1 rack1       Up     Normal  2.47 GB         20.00%
>>    datacenter1 rack1       Up     Normal  2.52 GB         20.00%
>>    datacenter1 rack1       Up     Normal  950.97 MB       20.00%
>>    datacenter1 rack1       Up     Normal  383.25 MB       20.00%
>> The nodes with ReplicateOnWrites are the 3 in the middle.  The first node and last
node both have a count of 0.  This is a clean cluster, and I've been doing 3k ... 2.5k (decaying
performance) inserts/sec for the last 12 hours.  The last time this test ran, it went all
the way down to 500 inserts/sec before I killed it.
> Could be due to
> --
> Sylvain

View raw message