jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Manes (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-5042) Improve caching of segments
Date Wed, 01 Mar 2017 04:50:46 GMT

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

Ben Manes commented on OAK-5042:

If you record an access trace (e.g. hashes) then we could [simulate|https://github.com/ben-manes/caffeine/wiki/Simulator]
it. That might help if you think its a policy issue (e.g. between random, lru, lirs).

> 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