jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: [Document Cache Size] Is it better to have cache size using number of entries
Date Tue, 19 Aug 2014 13:27:18 GMT
Hi Thomas,

On Tue, Aug 19, 2014 at 6:13 PM, Thomas Mueller <mueller@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

Mime
View raw message