While investigating a performance issue on a production server we found out that the window cache
never reaches its full capacity which we configured as: core.packedGitLimit=96G.
We set Xmx (and Xms) to 256G.
We found out that the window cache grows in average to about 10G and then gets wiped off by the Java GC.
This graph shows the jgit/block_cache/cache_used metric over time:
The drops in the window cache size correlate with the heap consumption peaks.
Given that JGit uses SoftReference for WindowCache entries [1], it is no surprise that Java GC is allowed to collect such entries if necessary.
We tried increasing the XX:SoftRefLRUPolicyMSPerMB by the factor of 10 (set it to 10,000 as the default value is 1000) but this seems to only bring small improvements.
However, we think that we should have more control over the eviction of the window cache and not just hope that Java GC will not wipe it off? WDYT?
Shall we change the window cache in JGit to use hard references or at least make this configurable in JGit?
I would also be interested if admins of large Gerrit servers can share their time series for the metric jgit/block_cache/cache_used and the core.packedGitLimit value and the max heap size.
