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] [Commented] (OAK-5042) Improve caching of segments
Date Wed, 01 Mar 2017 10:45:45 GMT

    [ https://issues.apache.org/jira/browse/OAK-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889955#comment-15889955

Michael Dürig commented on OAK-5042:

[~ben.manes] this looks interesting, thanks for sharing! The situation in this particular
case is a bit more involved though as the segment cache is actually a 2nd level cache. The
reason why the {{cache}} and {{cache2}} implementations above are superior is because they
use recency information from the 1st level cache in their eviction strategies. I guess this
is not easily captures in access traces. 

> Improve caching of segments
> ---------------------------
>                 Key: OAK-5042
>                 URL: https://issues.apache.org/jira/browse/OAK-5042
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: segment-tar
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>              Labels: performance, scalability
>             Fix For: 1.8, 1.7.1
>         Attachments: OAK-5042.png
> Various aspects of how Segment Tar caches segments could possibly improved. The current
cache is a result of replacing the former ad-hoc cache with a proper one in OAK-3055. While
the former was prone to contention under concurrent load the current cache is too oblivious
about reads: read accesses are always served through {{SegmentId.segment}} and never actually
hit the cache. This results in frequently accessed segments not to be seen as such by the
cache and potentially being prematurely evicted. 
> Possibly approaches to address this problem include: 
> * Reinstantiating the cache we had pre OAK-3055 but making in fully concurrent. 
> * Convey the information about read accesses to the current cache. 
> * In either of the above cases avoid bulk segments from being placed into the cache.

This message was sent by Atlassian JIRA

View raw message