Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <316547ca-adea-e7ff-94cf-c6cd0d8c398e@me.com>
References: <AANLkTinaWgzUr_gfOH9fUAP0jRDmX7civywn0+H=-9zn@mail.gmail.com>
	<316547ca-adea-e7ff-94cf-c6cd0d8c398e@me.com>
Date: Mon, 18 Oct 2010 23:13:40 +0200
Message-ID: <AANLkTik+0Ro2zCty3uKGWjVA3qUM2Lcm0Sun783uGCsc@mail.gmail.com>
Subject: Re: KeysCached - clarification and recommendations on settings
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Is your entire keyset active? If not set a sane starting point (default f=
or
> key cache is 200,000=C2=A0http://wiki.apache.org/cassandra/StorageConfigu=
ration=C2=A0)
> =C2=A0and see what the cache hit's are like. How many keys do you have? W=
hat
> was=C2=A0your=C2=A0hit rate with 100% key cache?

Also, keep in mind that the key cache will only eliminate one seek
(finding row position in the index is exactly one seek, unless cached
by the OS). Even if you dedicate your entire memory to JVM heap and
fill it with key cache, you will never do better than avoiding the
*one* seek per read. If your entire memory is wasted on key cache,
you'll take the row seek anyway so you only eliminated at most half
the overhead.

In the best case, the row is cached and the key saved you from going
to disk. In such a case, the key cache gave you quite a lot. But keep
in mind that if your data size is such that most row reads are cached
by the OS, then probably most index accesses would be too assuming the
rows are significantly bigger than the index (which is normal).

I'd say the key cache is most effective when your active set is small
enough that a reasonably sized key cache will eliminate the majority
of seeks on reads without blowing away significant amounts of memory.
Especially now in 0.7 (is it backported to 0.6.x?) where the key cache
is efficiently saved and re-loaded on start, giving you guaranteed
hotness of the key cache. Also the bigger discrepancy between row size
and key size, the more useful I would expect the key cache to be
(i.e., the fatter the rows, the more useful the key cache).

Ok, that was a bit unclearly stated... I'm not sure how to phrase it
sensibly. I guess the bottom line is that unless you specifically know
you need to and there are special circumstances, the key cache should
likely not be huge in comparison to available memory.

--=20
/ Peter Schuller