[rules-users] Needs advice to help Drools on a big problem (and avoid GC overhead)

[Raphael Jolivet]

Thanks for you quick answer.

Not yet,

For that I will need to switch to fact insertion instead of Java Set.
Do you think to will make a difference in the way the RETE Tree will be
built ?




2014-03-20 20:27 GMT+01:00 Mark Proctor <mproctor at codehaus.org>:

> Did you try using the engine in equality mode? It will only ever allow one
> "equal" object to be inserted, others are just ignored.
>
> Mark
> On 20 Mar 2014, at 18:54, Raphael <raphael.jolivet at gmail.com> wrote:
>
> > Hi,
> >
> > In our project, we use Drools to compute forbidden allocations as input
> for
> > an allocation problem  (for which we do not use Drools BTW).
> >
> > The constraint of the problem (forbidden operation for given resources)
> are
> > expressed as drools rules.
> >
> > We have about
> > -200 resources
> > -700 operations
> >
> > Those are the Drools facts.
> > We have about 200 Drools rules describing the forbidden allocations
> >
> > The problem here is that many rules produce duplicates forbids.
> > For instance :
> > Rule 1 may forbid Op1 on Res1 & Res3
> > Rule 2 may forbid Op1 on Res2 & res3
> >
> > Currently the RHS of rules just insert forbids into a pure Java Set (no
> fact
> > insertion).
> > The Set takes care of avoiding duplicates, but still, we feel we could
> help
> > Drools by giving him a hint that
> > all rules are actually producing pairs of <Resource, Allocation> and
> that he
> > should not try to produce them more than once.
> >
> > Currently the structure of each rule looks like that :
> >
> > when
> > $resource : Resource(<someconditions>)
> > $operation : Operation(<someconditions>)
> > then
> >  globalSet.add(Pair<resrouce, operation>)
> > end
> >
> > With the size of the problem, we often end up with outOfMem/ GC limit.
> > When analyzing memory dump, we see about
> > 300.000 drools left tuple object.
> >
> > I am not sure if we could help drools to reduce the Rete tree here.
> > I mean, the allocation matrix is already : 200*700 = 140.000 cells.
> > Drools only uses 2 nodes for each possible forbids, which seems already
> well
> > optimized.
> >
> > We had several idea to improve that though, but we are not enough expert
> in
> > the internal of the RETE algorithm to decide if that's a good way to go :
> >
> > 1) Insert forbids as facts in the RHS and check they are not already
> there
> > in the LHS :
> > when
> > $resource : Resource(<someconditions>)
> > $operation : Operation(<someconditions>)
> > not Forbid(res=$resource, op=$operation)
> > then
> >  insert(Forbid($resource, $operation))
> > end
> >
> > 2) Merge all rules in one big rule with a single RHS
> > Is it possible to have something like :
> > when
> > // Rule 1
> > ($resource : Resource(<someconditions>)
> > $operation : Operation(<someconditions>))
> >  or
> > // Rule 2
> > ($resource : Resource(<someconditions>)
> > $operation : Operation(<someconditions>))
> > // Etc ...
> > then
> >  globalSet.add(Pair<resrouce, operation>)
> > end
> >
> > 3) Define a common RHS somewhere and tell Drools all rules use this one.
> > Is there a possibility in Drools to define reusable RHS ? Would it help ?
> >
> > 4) Any other idea ?
> >
> >
> > Thanks in advance for your help.
> > Brgds,
> >
> > Raphael Jolivet
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://drools.46999.n3.nabble.com/Needs-advice-to-help-Drools-on-a-big-problem-and-avoid-GC-overhead-tp4028838.html
> > Sent from the Drools: User forum mailing list archive at Nabble.com.
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140320/67c1af27/attachment.html