[
https://issues.apache.org/jira/browse/OAK-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110621#comment-15110621
]
Alex Parvulescu commented on OAK-3889:
--------------------------------------
thanks [~mreutegg] for the pointer! I will update the patch to include both
(key, value) in the estimation, plus overhead, it was not clear to me that the
overhead was supposed to the included manually.
On more thing, the current overhead is at {{168}}? any insight into how this
number was obtained?
bq. It would probably be better if this value was provided by the Cache
implementation.
I agree it would be nice if the cache took care of estimating its internals,
and the users would only estimate the (key, value) pair. [~tmueller] would this
qualify as a feature request? :)
> SegmentMk StringCache memory leak
> ---------------------------------
>
> Key: OAK-3889
> URL: https://issues.apache.org/jira/browse/OAK-3889
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Reporter: Alex Parvulescu
> Attachments: CacheLIRS-Entry-heap.png, OAK-3889-v2.patch,
> StringCache.java.patch
>
>
> The StringCache is made of 2 components: a FastCache and a Lirs Cache and
> both caches use the same key object 'StringCacheEntry' with the condition
> that the FastCache contains the string value itself with the key while the
> Lirs Cache will only contain the _msb_, _lsb_ and _offset_.
> Sharing the same key leads to issues when a value qualifies for both caches
> as it results in the string value ending up contained in the Lirs Cache,
> effectively blowing up the cache's size. [0]
> On a test I ran I noticed the Lirs Cache going up to 800mb even though it was
> configured at 256mb.
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/StringCache.java#L86
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
