jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chetan Mehrotra (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-2557) VersionGC uses way too much memory if there is a large pile of garbage
Date Mon, 02 Mar 2015 08:24:04 GMT

    [ 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)

Mime
View raw message