[rules-dev] memory issue (memory leak?) on trunk (probably due true modify changes)
Michael Neale
michael.neale at gmail.com
Sat Mar 13 22:24:28 EST 2010
well it is interesting that it means 98% of the time it is GC doing the
work. Think about that - that means if it is only 90% GC doing the work (ie
90% of CPU time is spent running the garbage collector - and freeing enough
memory to keep it happy) than it would not trip this error - but I am sure
no one would be happy with an application that runs that way !
On Sun, Mar 14, 2010 at 12:50 PM, Greg Barton <greg_barton at yahoo.com> 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.
>
> --- On Sat, 3/13/10, Michael Neale <michael.neale at gmail.com> wrote:
>
> > From: Michael Neale <michael.neale at gmail.com>
> > Subject: Re: [rules-dev] memory issue (memory leak?) on trunk (probably
> due true modify changes)
> > To: "Rules Dev List" <rules-dev at lists.jboss.org>
> > Cc: "rules-dev at lists.jboss.org" <rules-dev at lists.jboss.org>
> > 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 <ge0ffrey.spam at gmail.com>
> >
> > 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
> > > rules-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-dev
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100314/a25c5ebd/attachment.html
More information about the rules-dev
mailing list