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 "Francesco Mari (JIRA)" <ji...@apache.org> on 2016/03/04 11:25:40 UTC
[jira] [Assigned] (OAK-4088) CacheLIRS prevents cleanup from being
effective
[ https://issues.apache.org/jira/browse/OAK-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francesco Mari reassigned OAK-4088:
-----------------------------------
Assignee: Francesco Mari
> 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.6
>
>
> 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)