[
https://issues.apache.org/jira/browse/OAK-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341522#comment-14341522
]
Stefan Egli commented on OAK-2557:
----------------------------------
Here's a stacktrace that keeps showing up when this particular VM is running
into low memory/full-gc-loops:
{code}
"pool-5-thread-5" prio=10 tid=0x0000000001413800 nid=0x1aa5 runnable
[0x00007f247599f000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.addEntry(HashMap.java:884)
at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:427)
at java.util.HashMap.put(HashMap.java:505)
at org.bson.BasicBSONObject.put(BasicBSONObject.java:288)
at org.bson.BasicBSONCallback._put(BasicBSONCallback.java:184)
at org.bson.BasicBSONCallback.gotLong(BasicBSONCallback.java:132)
at org.bson.BasicBSONDecoder.decodeElement(BasicBSONDecoder.java:222)
at org.bson.BasicBSONDecoder._decode(BasicBSONDecoder.java:154)
at org.bson.BasicBSONDecoder.decode(BasicBSONDecoder.java:132)
at com.mongodb.DefaultDBDecoder.decode(DefaultDBDecoder.java:62)
at com.mongodb.Response.<init>(Response.java:85)
at com.mongodb.DBPort$1.execute(DBPort.java:141)
at com.mongodb.DBPort$1.execute(DBPort.java:135)
at com.mongodb.DBPort.doOperation(DBPort.java:164)
- locked <0x000000064f6049d0> (a com.mongodb.DBPort)
at com.mongodb.DBPort.call(DBPort.java:135)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:292)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:271)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:237)
at com.mongodb.QueryResultIterator.getMore(QueryResultIterator.java:137)
at com.mongodb.QueryResultIterator.hasNext(QueryResultIterator.java:127)
at com.mongodb.DBCursor._hasNext(DBCursor.java:551)
at com.mongodb.DBCursor.hasNext(DBCursor.java:571)
at
com.google.common.collect.TransformedIterator.hasNext(TransformedIterator.java:43)
at
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.collectDeletedDocuments(VersionGarbageCollector.java:95)
at
org.apache.jackrabbit.oak.plugins.document.VersionGarbageCollector.gc(VersionGarbageCollector.java:79)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService$2.run(DocumentNodeStoreService.java:472)
at
org.apache.jackrabbit.oak.spi.state.RevisionGC$1.call(RevisionGC.java:68)
at
org.apache.jackrabbit.oak.spi.state.RevisionGC$1.call(RevisionGC.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
> 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
>
> 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)
