[
https://issues.apache.org/jira/browse/OAK-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110710#comment-15110710
]
Marcel Reutegger commented on OAK-3889:
---------------------------------------
bq. On more thing, the current overhead is at 168? any insight into how this
number was obtained?
I don't remember exactly, but I think I looked at the heap usage with
MemoryAnalyzer. It is also quite likely that the overhead is tied to the Guava
Cache implementation because it was the default back then.
> 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)
