[ https://issues.apache.org/jira/browse/OAK-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355322#comment-14355322 ]
Stefan Egli commented on OAK-2557: ---------------------------------- {{<feature-creep-warning>}} we could make the VersionGC play nicely to existing load on the system: it could progress slower if the load is higher and vice-verca. One simple measure could be: if the observation queue is small (eg below 10) then the load is low and it could progress full-speed. Otherwise it could add some artificial sleeping in between. {{</feature-creep-warning>}} > 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 > Assignee: Chetan Mehrotra > Priority: Blocker > Fix For: 1.0.13, 1.2 > > Attachments: OAK-2557.patch > > > 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)