(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
