If the cache is stored in the heap, how big can the heap be made realistically on a 24gb ram machine? I am a java newbie but I have read concerns with going over 8gb for the heap as the GC can be too painful/take too long. I already have seen timeout issues (node is dead errors) under load during GC or compaction. Can/should the heap be set to 16gb with 24gb ram?
On Mon, Jul 26, 2010 at 12:49 PM, Peter Schuller < peter.schul...@infidyne.com> wrote: > (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 >
