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. >> >> >
