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 "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2015/03/02 09:24:04 UTC

[jira] [Commented] (OAK-2557) VersionGC uses way too much memory if there is a large pile of garbage

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

Chetan Mehrotra commented on OAK-2557:
--------------------------------------

{{docIdsToDelete}} is just a set of string ids to be deleted? Is that set becoming too large to cause an OOM? Do we have access to the heapdump to determine the size of set. We can possibly change the logic to delete once we have got say 500 ids collected but before that would like to confirm if thats the case here

> VersionGC uses way too much memory if there is a large pile of garbage
> ----------------------------------------------------------------------
>
>                 Key: OAK-2557
>                 URL: https://issues.apache.org/jira/browse/OAK-2557
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core, mongomk
>    Affects Versions: 1.0.11
>            Reporter: Stefan Egli
>            Priority: Blocker
>             Fix For: 1.2, 1.0.12
>
>
> It has been noticed that on a system where revision-gc (VersionGarbageCollector of mongomk) did not run for a few days (due to not interfering with some tests/large bulk operations) that there was such a large pile of garbage accumulating, that the following code
> {code}
> VersionGarbageCollector.collectDeletedDocuments
> {code}
> in the for loop, creates such a large list of NodeDocuments to delete (docIdsToDelete) that it uses up too much memory, causing the JVM's GC to constantly spin in Full-GCs.



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