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-4293) Refactor / rework compaction gain estimation
Date Mon, 25 Jul 2016 08:16:20 GMT

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

Michael Dürig commented on OAK-4293:
------------------------------------

One idea would be to base the decision whether to run gc on the size increase of the repository
since the last gc run. I.e. run gc if the repository increased by more than 10GB (configurable),
otherwise skip it. 

[~alex.parvulescu], [~frm] WDYT?

> Refactor / rework compaction gain estimation 
> ---------------------------------------------
>
>                 Key: OAK-4293
>                 URL: https://issues.apache.org/jira/browse/OAK-4293
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: segment-tar
>            Reporter: Michael Dürig
>            Assignee: Alex Parvulescu
>              Labels: gc
>             Fix For: 1.6, Segment Tar 0.0.8
>
>
> I think we have to take another look at {{CompactionGainEstimate}} and see whether we
can up with a more efficient way to estimate the compaction gain. The current implementation
is expensive wrt. IO, CPU and cache coherence. If we want to keep an estimation step we need
IMO come up with a cheap way (at least 2 orders of magnitude cheaper than compaction). Otherwise
I would actually propose to remove the current estimation approach entirely 



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

Mime
View raw message