You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2015/08/04 12:45:04 UTC

[jira] [Resolved] (OAK-3168) SegmentCache flushes Segment on update

     [ https://issues.apache.org/jira/browse/OAK-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dürig resolved OAK-3168.
--------------------------------
    Resolution: Fixed

Fixed at proposed at http://svn.apache.org/r1694022.

With this I see the problem going away. [~alex.parvulescu], please reopen if you disagree. 

> SegmentCache flushes Segment on update
> --------------------------------------
>
>                 Key: OAK-3168
>                 URL: https://issues.apache.org/jira/browse/OAK-3168
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: segmentmk
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>             Fix For: 1.3.5
>
>
> The SegmentCache currently uses the cache eviction call to remove the Segment instance from memory to help keep the cache memory requirements under control [0].
> What I've noticed though, is that for a cache update (existing key) there will also be an eviction call happening, which results in a lot of extra IO pressure on the SegmentStore which not only is not able to cache the segment, but is forced to reload it multiple times as the reference gets nullified after each load.
> This comes from the sampling behavior of the SegmentId: it will not hit the cache each time it needs to load a new Segment, but rather load it from IO and (re)place it in the cache, based on a sampling rate [1].
> Now I see 2 options:
>  * change the cache code to _not_ call the eviction callback on updates (or allow disabling this call on updates)
>  * change the SegmentTracker code to add the value to the cache only if it's not there as Segments are immutable, so no harm done.
> Raised this issue offline with [~tmueller], [~mduerig] first and as I understand [~mduerig] is in favor of option one, while [~tmueller] proposed that the Lirs cache impl should be inline with what the guava cache does, and depending on that we could choose the right fix here. 
> Hope this covers everything.
> [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentTracker.java#L133
> [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/SegmentId.java#L135



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)