On 14/03/2010 01:50, Greg Barton wrote: > Isn't that what Geoffrey just said? :) > > Anyone tried different GC approaches with this? Running with the concurrent > collector might be a useful stopgap until the object creation is tamped down. > The new algorithm should now have less objects created than before, so this indicates something is wrong somewhere.
Mark > --- On Sat, 3/13/10, Michael Neale<[email protected]> wrote: > > >> From: Michael Neale<[email protected]> >> Subject: Re: [rules-dev] memory issue (memory leak?) on trunk (probably due >> true modify changes) >> To: "Rules Dev List"<[email protected]> >> Cc: "[email protected]"<[email protected]> >> Date: Saturday, March 13, 2010, 5:54 PM >> Interesting error. >> >> One explanation of it: >> http://stackoverflow.com/questions/1393486/what-means-the-error-message-java-lang-outofmemoryerror-gc-overhead-limit-excee >> >> Sent from my phone. >> >> On 13/03/2010, at 8:21 PM, Geoffrey De Smet<[email protected]> >> >> wrote: >> >> >>> Hi guys, >>> >>> With great improvements usually come instability for a >>> >> while :) >> >>> Trunk has memory issue, probably a memory leak of a >>> >> small object. >> >>> I've run ExmaminationBenchmarkApp with the program arg >>> >> "short" 3 times >> >>> with the exact same configuration (it is a 100% >>> >> reproducible run): >> >>> 1) Before the true modify changes with 512m max >>> >> memory >> >>> Succeeds (100 steps but even 10000 steps work) with no >>> >> slow down. >> >>> 2) After true modify changes with 512m max memory >>> Fails after 27 steps, starts slowing down at 24 >>> >> steps. >> >>> 3) After true modify changes with 1024m max memory >>> Fails after 57 steps, starts slowing down at 54 >>> >> steps. >> >>> Both 2) and 3) fail with the exception: >>> Exception in thread "main" java.lang.OutOfMemoryError: >>> >> GC overhead >> >>> limit >>> exceeded >>> >>> So it's not a heap space error or a perm space error, >>> >> but a GC >> >>> overhead >>> limit instead. Literally this means it's doing more GC >>> >> then running, >> >>> but 99% of the time this means that the heap is so >>> >> full that the GC >> >>> has >>> little or no free space to work with. >>> This kind of memory leak happens when the iteration >>> >> make 101 objects >> >>> but >>> only removes 100 objects and the iteration is run a >>> >> lot (like 10000+ >> >>> times). >>> You don't get a heap space error, because before that >>> >> happens, >> >>> there is point where you have a garbaged collected >>> >> free memory for 10 >> >>> objects and a ungarbaged collected free memory for 100 >>> >> objects. At >> >>> that >>> point the GC is running over 98% of the time, which is >>> >> a VM treshold >> >>> and >>> the error is thrown, >>> even though 10 iterations later you would get a heap >>> >> space error. >> >>> >>> Logs: >>> >>> 1) >>> TODO >>> >>> 2) >>> 2010-03-13 09:28:36,973 [main] INFO Step index >>> >> (21), time spend >> >>> (37245) >>> taking step (323 {D180|S9} @ 9 {D210} + 5 {C65} => >>> >> 52 {D210}) out of >> >>> 1402 accepted moves. >>> 2010-03-13 09:28:38,454 [main] INFO Step index >>> >> (22), time spend >> >>> (38727) >>> taking step (367 {D190|S40} @ 28 {D210} + 5 {C65} >>> >> => 19 {D210}) out of >> >>> 1366 accepted moves. >>> 2010-03-13 09:28:39,903 [main] INFO Step index >>> >> (23), time spend >> >>> (40176) >>> taking step (230 {D120|S15} @ 7 {D210} + 3 {C60} => >>> >> 12 {D210}) out of >> >>> 1366 accepted moves. >>> 2010-03-13 09:28:43,901 [main] INFO Step index >>> >> (24), time spend >> >>> (44174) >>> taking step (190 {D90|S6} @ 1 {D210} + 3 {C60} >>> >> <=> 205 {D120|S6} @ 8 >> >>> {D210} + 6 {C111}) out of 1392 accepted moves. >>> 2010-03-13 09:28:50,631 [main] INFO Step index >>> >> (25), time spend >> >>> (50904) >>> taking step (420 {D180|S6} @ 46 {D210} + 2 {C129} >>> >> => 25 {D210}) out of >> >>> 1396 accepted moves. >>> 2010-03-13 09:29:06,184 [main] INFO Step index >>> >> (26), time spend >> >>> (66457) >>> taking step (211 {D180|S53} @ 15 {D210} + 0 {C260} >>> >> => 23 {D210}) out >> >>> of >>> 1383 accepted moves. >>> 2010-03-13 09:29:46,589 [main] INFO Step index >>> >> (27), time spend >> >>> (106862) taking step (39 {D120|S15} @ 50 {D210} + 2 >>> >> {C129} => 43 >> >>> {D210}) >>> out of 1383 accepted moves. >>> Exception in thread "main" java.lang.OutOfMemoryError: >>> >> GC overhead >> >>> limit >>> exceeded >>> at >>> >> java.util.HashMap.addEntry(HashMap.java:753) >> >>> at >>> >> java.util.HashMap.put(HashMap.java:385) >> >>> at >>> >> java.util.HashMap.putAll(HashMap.java:524) >> >>> at >>> org.drools.rule.GroupElement$Type.getOuterDeclarations >>> >> >>> (GroupElement.java:406) >>> at >>> >> org.drools.rule.GroupElement.getOuterDeclarations >> >>> (GroupElement.java:109) >>> at >>> org.drools.base.DefaultKnowledgeHelper.getDeclaration >>> >> >>> (DefaultKnowledgeHelper.java:213) >>> at >>> >>> >> org.drools.planner.examples.examination.solver.Rule_periodSpread_0DefaultConsequenceInvoker.evaluate( >> >> >>> Rule_periodSpread_0DefaultConsequenceInvoker.java:21) >>> at >>> >> org.drools.common.DefaultAgenda.fireActivation >> >>> (DefaultAgenda.java:903) >>> at >>> >> org.drools.common.DefaultAgenda.fireNextItem >> >>> (DefaultAgenda.java:850) >>> at >>> >> org.drools.common.DefaultAgenda.fireAllRules >> >>> (DefaultAgenda.java:1061) >>> at >>> org.drools.common.AbstractWorkingMemory.fireAllRules >>> (AbstractWorkingMemory.java:741) >>> at >>> org.drools.common.AbstractWorkingMemory.fireAllRules >>> (AbstractWorkingMemory.java:707) >>> ... >>> >>> 3) >>> 2010-03-13 09:47:38,303 [main] INFO Step index >>> >> (55), time spend >> >>> (114213) taking step (186 {D90|S17} @ 24 {D210} + 5 >>> >> {C65}<=> 516 >> >>> {D180|S12} @ 15 {D210} + 0 {C260}) out of 1382 >>> >> accepted moves. >> >>> 2010-03-13 09:48:02,062 [main] INFO Step index >>> >> (56), time spend >> >>> (137972) taking step (498 {D120|S17} @ 28 {D210} + 0 >>> >> {C260} => 1 >> >>> {C100}) >>> out of 1389 accepted moves. >>> 2010-03-13 09:48:35,748 [main] INFO Step index >>> >> (57), time spend >> >>> (171658) taking step (15 {D135|S96} @ 16 {D210} + 1 >>> >> {C100}<=> 164 >> >>> {D180|S48} @ 3 {D210} + 0 {C260}) out of 1378 accepted >>> >> moves. >> >>> Exception in thread "main" java.lang.OutOfMemoryError: >>> >> GC overhead >> >>> limit >>> exceeded >>> at >>> >> java.lang.Integer.valueOf(Integer.java:625) >> >>> at >>> >>> >> org.drools.common.TruthMaintenanceSystem.removeLogicalDependencies >> >> >>> (TruthMaintenanceSystem.java:180) >>> at >>> >>> >> org.drools.common.AbstractWorkingMemory.removeLogicalDependencies >> >> >>> (AbstractWorkingMemory.java:1455) >>> at >>> org.drools.reteoo.RuleTerminalNode.retractLeftTuple >>> (RuleTerminalNode.java:266) >>> at >>> >>> >> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple( >> >> >>> SingleLeftTupleSinkAdapter.java:176) >>> at >>> >>> >> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple( >> >> >>> SingleLeftTupleSinkAdapter.java:57) >>> at >>> org.drools.reteoo.EvalConditionNode.modifyLeftTuple >>> (EvalConditionNode.java:250) >>> at >>> >>> >> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple( >> >> >>> SingleLeftTupleSinkAdapter.java:198) >>> at >>> >> org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:304) >> >>> at >>> >>> >> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple( >> >> >>> SingleLeftTupleSinkAdapter.java:209) >>> at >>> >> org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:221) >> >>> at >>> >> org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:317) >> >>> at >>> >>> >> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject >> >> >>> (CompositeObjectSinkAdapter.java:444) >>> at >>> >>> >> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject >> >> >>> (CompositeObjectSinkAdapter.java:412) >>> at >>> >> org.drools.reteoo.ObjectTypeNode.modifyObject >> >>> (ObjectTypeNode.java:262) >>> at >>> >> org.drools.reteoo.EntryPointNode.modifyObject >> >>> (EntryPointNode.java:174) >>> at >>> org.drools.common.AbstractWorkingMemory.update >>> (AbstractWorkingMemory.java:1392) >>> at >>> org.drools.common.AbstractWorkingMemory.update >>> (AbstractWorkingMemory.java:1288) >>> >>> >>> -- >>> With kind regards, >>> Geoffrey De Smet >>> >>> _______________________________________________ >>> rules-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
