[
https://issues.apache.org/jira/browse/OAK-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110451#comment-15110451
]
Marcel Reutegger commented on OAK-3889:
---------------------------------------
For the DocumentMK we use the {{EmpiricalWeigher}}, which has a hard coded
overhead per cache entry. It would probably be better if this value was
provided by the Cache implementation. Our CacheLIRS and the Guava Cache
probably have different overhead per entry.
> 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)
