(the following are best-effort answers resulting from taking the
opportunity to look at the source; i may be missing something)

> I am trying to use the key cache, and I had some basic questions as to how
> it works. There seem to be settings based on % and total count, but not on
> total cache size like most caching mechanisms. Is the cache stored in the
> jvm heap or somewhere else?

In the heap (I'm almost but not entirely sure). The key cache seems to
be backed by a ConcurrentLinkedHashMap, which I think is the same one
that eventually moved to another Java package and is over here:
   
http://code.google.com/p/concurrentlinkedhashmap/source/browse/branches/lru/src/java/com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.java

> What is the the key cache capacity in cfstats? How is this calculated? I
> also see the stats get reset often and cache is cleared quite often, what
> triggers the flushing of key cache? Is it compaction? Given that our keys do

I'm not sure about the stats, but looking at SSTableTracker and
SSTableReader I believe the cache entries are keyed on both row key
and the path to the sstable in which the data resides. I didn't find
any code indicating that cached keys are preserved (but modified) as a
result of sstable replacement (as a result of compaction), so I
*think* it is expected that cache hit ratio will drop as a result of
compaction. Can anyone confirm/deny?

-- 
/ Peter Schuller

Reply via email to