incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tsuraan <tsur...@gmail.com>
Subject Re: Cassandra behaviour
Date Mon, 26 Jul 2010 18:35:55 GMT
> Bloom filters are indeed linear in size with respect to the number of
> items (assuming a constant target false positive rate). While I have
> not looked at how Cassandra calculates the bloom filter sizes, I feel
> pretty confident in saying that it won't dynamically replace bloom
> filters with filters of smaller sizes in response to memory pressure.
> The number of implementation issues involved in doing that are many,
> just that I can think of off the top of my head ;)
>
> Also keep in mind that, at least as far as I can tell, silently
> sacrificing false positive rates would not necessarily be an optimal
> thing to do anyway.

Well, it would probably kill the lookup speeds.  I'm not testing that
right now, so I wouldn't notice until I do :)  I suppose that since
bloom filters are stored alongside their associated data on-disk,
having their size dependent on the RAM in the current machine wouldn't
be the most portable thing to do.  I had been thinking that the bloom
filters were created on startup, but further reading of the docs
indicates that they are in the SSTable Index.  What is cassandra
doing, then, when it's printing out that it's sampling indices while
it starts?

> One aspect of start-up is reading through indexes, which will take
> some time linear in the size of the indexes. Given 120M entries this
> should not take terribly long.
>
> WIth respect to compaction: In general, compactions may take up to
> whatever time it takes to read and write the entire data set (in the
> case of a full compaction). In addition, if your test threw write
> traffic at the node faster than it was able to do compaction, you may
> have a built-up backlog of compaction activity. I'm pretty sure there
> is no active feedback mechanism (yet anyway) to prevent this from
> happening (though IIRC it's been discussed on the lists).

I think that is what happened; in the INFO printouts, it was saying
CompactionManager had 50+ pending operations.  If I set commitlog_sync
to batch and commitlog_sync_period_in_ms to 0, then cassandra can't
write data any faster than my drives can keep up, right?  Would that
have any effect in preventing a huge compaction backlog, or would it
just thrash my drives a ton?

> For a database with many items I would start by:
>
> * Increasing the memtable size. Increasing memtable size directly
> affects the number of times a given entry will end up having to be
> compacted on average; i.e., it decreases the total compaction work
> that must be done for a given insertion workload. The default is
> something like 64 MB; on a large system you probably want this
> significantly larger, even up to several gigs (depending on heap sizes
> and other concerns of course).

Is that {binary_,}memtable_throughput_in_mb?  It definitely sounds
like fewer compactions would help me, so I will give that a shot.

> * Making sure enough memory is reserved for the bloom filters.

Is this anything other than ensuring that -Xmx in JVM_OPTS is
something reasonably large?

> For sustaining high read traffic you may then want to tweak cache
> sizes, but that should not affect insertion.

Yeah, I haven't done any reads yet, so I'll play with that later.

Mime
View raw message