incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Minimizing the impact of compaction on latency and throughput
Date Wed, 07 Jul 2010 22:53:55 GMT
On Wed, Jul 7, 2010 at 4:57 PM, Peter Schuller
<peter.schuller@infidyne.com> wrote:
>> This makes sense, but from what I have seen, read contention vs
>> cassandra is a much bigger deal than write contention

(meant "read contention vs compaction")

> I am not really concerned with write performance, but rather with
> writes affecting reads. Cache eviction due to streaming writes has the
> obvious effect on hit ratio on reads, and in general large sustained
> writes tend to very negatively affect read latency (and typically in a
> bursty fashion). So; the idea was to specifically optimize to try to
> make reads be minimally affected by writes (in the sense of the
> background compaction eventually resulting from those writes).
>
> Understood and agreed about the commit log (though as long as write
> bursts are within what a battery-backed RAID controller can keep in
> its cache I'd expect it to potentially work pretty well without
> separation, if you do have such a setup).

It might be worth experimenting with posix_fadvise.  I don't think
implementing our own i/o scheduler or rate-limiter would be as good a
use of time (it sounds like you're on that page too).

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com

Mime
View raw message