jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Updated] (OAK-3168) SegmentCache flushes Segment on update
Date Fri, 11 Dec 2015 11:26:11 GMT

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

Michael Dürig updated OAK-3168:
-------------------------------
    Labels: candidate_oak_1_0 candidate_oak_1_2  (was: )

> 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
>              Labels: candidate_oak_1_0, candidate_oak_1_2
>             Fix For: 1.3.4
>
>
> 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)

Mime
View raw message