incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohit Anchlia <mohitanch...@gmail.com>
Subject Re: row cache
Date Sun, 08 Sep 2013 02:24:02 GMT
I agree. We've had similar experience.

Sent from my iPhone

On Sep 7, 2013, at 6:05 PM, Edward Capriolo <edlinuxguru@gmail.com> wrote:

> I have found row cache to be more trouble then bene.
> 
> The term fools gold comes to mind.
> 
> Using key cache and leaving more free main memory seems stable and does not have as many
complications. 
> On Wednesday, September 4, 2013, S C <asf11@outlook.com> wrote:
> > Thank you all for your valuable comments and information.
> >
> > -SC
> >
> >
> >> Date: Tue, 3 Sep 2013 12:01:59 -0400
> >> From: chris.burroughs@gmail.com
> >> To: user@cassandra.apache.org
> >> CC: fsareshwala@quantcast.com
> >> Subject: Re: row cache
> >>
> >> On 09/01/2013 03:06 PM, Faraaz Sareshwala wrote:
> >> > Yes, that is correct.
> >> >
> >> > The SerializingCacheProvider stores row cache contents off heap. I believe
you
> >> > need JNA enabled for this though. Someone please correct me if I am wrong
here.
> >> >
> >> > The ConcurrentLinkedHashCacheProvider stores row cache contents on the
java heap
> >> > itself.
> >> >
> >>
> >> Naming things is hard. Both caches are in memory and are backed by a
> >> ConcurrentLinkekHashMap. In the case of the SerializingCacheProvider
> >> the *values* are stored in off heap buffers. Both must store a half
> >> dozen or so objects (on heap) per entry
> >> (org.apache.cassandra.cache.RowCacheKey,
> >> com.googlecode.concurrentlinkedhashmap.ConcurrentLinkedHashMap$WeightedValue,
> >> java.util.concurrent.ConcurrentHashMap$HashEntry, etc). It would
> >> probably be better to call this a "mixed-heap" rather than off-heap
> >> cache. You may find the number of entires you can hold without gc
> >> problems to be surprising low (relative to say memcached, or physical
> >> memory on modern hardware).
> >>
> >> Invalidating a column with SerializingCacheProvider invalidates the
> >> entire row while with ConcurrentLinkedHashCacheProvider it does not.
> >> SerializingCacheProvider does not require JNA.
> >>
> >> Both also use memory estimation of the size (of the values only) to
> >> determine the total number of entries retained. Estimating the size of
> >> the totally on-heap ConcurrentLinkedHashCacheProvider has historically
> >> been dicey since we switched from sizing in entries, and it has been
> >> removed in 2.0.0.
> >>
> >> As said elsewhere in this thread the utility of the row cache varies
> >> from "absolutely essential" to "source of numerous problems" depending
> >> on the specifics of the data model and request distribution.
> >>
> >>
> >

Mime
View raw message