jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Mari (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (OAK-4088) CacheLIRS prevents cleanup from being effective
Date Mon, 07 Mar 2016 14:09:40 GMT

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

Francesco Mari resolved OAK-4088.
---------------------------------
       Resolution: Not A Problem
    Fix Version/s:     (was: 1.6)
                   1.5.0

I tested the same deployment with three configurations:

- {{SegmentTracker}} with a LIRS cache using {{SegmentId}} instances as keys directly.
- {{SegmentTracker}} with a LIRS cache using a surrogate key of {{SegmentId}}.
- {{SegmentTracker}} using another cache implementation, more specifically an unbounded cache
from Guava.

The system behaved in comparable ways. The amount of in-memory references to {{SegmentId}}
and {{Segment}} instances is comparable with every tested configuration. 

It looks like that the bulk of the problem was not related to {{CacheLIRS}} - or to any cache
in general - but was instead caused by OAK-4089. After fixing OAK-4089, the system behaves
as expected. As such, I'm resolving this issue as not a problem.

> CacheLIRS prevents cleanup from being effective
> -----------------------------------------------
>
>                 Key: OAK-4088
>                 URL: https://issues.apache.org/jira/browse/OAK-4088
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, segmentmk, tarmk-standby
>            Reporter: Francesco Mari
>            Assignee: Francesco Mari
>             Fix For: 1.5.0
>
>
> While performing some tests on compaction in the context of the cold standby, I spotted
an issue involving {{CacheLIRS}} and the {{SegmentTracker}}.
> Cleanup on the standby store is inefficient due to many references to {{SegmentId}} instances.
These references prevent the system to identify unused segments, thus making the cleanup process
less effective. To minimise the amount of references to {{SegmentId}} instances, the current
implementation of the cleanup process forces every cache to be invalidated, including {{CacheLIRS}}.
Unluckily, even if {{CacheLIRS}} is invalidated, heap dumps show a lot of references to {{SegmentId}}
instances held by {{CacheLIRS}} and its inner classes. 
> To verify my hypothesis, I tried to run the system with an implementation of the {{SegmentTracker}}
that doesn't populate {{CacheLIRS}} - the cache is always empty. This greatly improved the
effectiveness of compaction, to the point that the standby instance is able to cleanup almost
the whole amount of unused segments.
> It should be investigated if this behaviour is caused by a bug in {{CacheLIRS}} or by
an incorrect usage of {{CacheLIRS}} by the {{SegmentTracker}}.



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

Mime
View raw message