[
https://issues.apache.org/jira/browse/OAK-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034766#comment-16034766
]
Julian Reschke commented on OAK-6303:
-------------------------------------
One thing to do is to make sure that the number of segments times the blocksize
isn't bigger than the maximal cache size. Right now we have 16 segments and 2
MB blocksize, so once every segment holds one block we already exceed the max
memory size.
To fix this, we could use something like
{code}
segmentCount((int)(cacheSize / getBlockSize())).
{code}
in the constructor of {{CachingBlobStore}}.
The other thing to look at is how the individual segments behave when trying to
evict entries and the number of entries is small (which will be the case in the
above test).
> Cache in CachingBlobStore might grow beyond configured limit
> ------------------------------------------------------------
>
> Key: OAK-6303
> URL: https://issues.apache.org/jira/browse/OAK-6303
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob, core
> Reporter: Julian Reschke
> Assignee: Thomas Mueller
> Attachments: OAK-6303-test.diff
>
>
> It appears that depending on actual cache entry sizes, the {{CacheLIRS}}
> might grow beyond the configured limit.
> For {{RDBBlobStore}}, the limit is currently configured to 16MB, yet storing
> random 2M entries appears to fill the cache with 64MB of data (according to
> it's own stats).
> The attached test case reproduces this.
> (it seems this is caused by the fact that each of the 16 segments of the
> cache can hold 2 entries, no matter how big they are...)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
