I agree. We've had similar experience. Sent from my iPhone
On Sep 7, 2013, at 6:05 PM, Edward Capriolo <edlinuxg...@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 <as...@outlook.com> wrote: > > Thank you all for your valuable comments and information. > > > > -SC > > > > > >> Date: Tue, 3 Sep 2013 12:01:59 -0400 > >> From: chris.burrou...@gmail.com > >> To: user@cassandra.apache.org > >> CC: fsareshw...@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. > >> > >> > >
