Hi Thomas, On Tue, Aug 19, 2014 at 6:13 PM, Thomas Mueller <muel...@adobe.com> wrote: > How, or in what way, is it more deterministic?
Missed providing some context there so here are the details. Currently we limit the cache by total size taken. Now given a system where you have say 32 GB RAM available to you and admin needs to decide how much memory one should allocate to DocumentNodeStore. Currently we do not have a definitive way to tell that as there are couple of factors to consider 1. Number of entries in Document Cache - The Document cache (which caches the NodeDocuments) is the most critical cache and is currently allocated 70% of the cache size. We would like to give it as much memory as possible but then we also need to take into account the time taken to perform consistency check for the entries present in the cache. If time taken to perform consistency checks take more than 1 sec then it would delay the background job in DocumentNodeStore and hence root node version would become stale. Now time taken to perform consistency check ~= f(n) where n = number of entries in the cache and not the size of cache. With Mongo we can have good estimate of time taken to query modCount for 'n' node. Going forward would add some stats collection in this logic to determine how much time is being spent in cache consistency check 2. Effect of GC with larger heaps - As we run JVM with higher heap size we need to take into account delays that might occur with such large heaps So if we can have a cache policy which can put up a max cap on memory taken and also allow limit of number of entries then that would give a more deterministic control on tuning the cache Chetan Mehrotra
