[rules-users] drools expert: memory issues

[Wolfgang Laun]

It should be possible to increase heap space to overcome this problem. Of
course, if a program wil start swapping, performance will go way down.

Dividing the rules file is the only way. But even a very simple script of
Perl or similar should be able to divide your (IIRC) generated rules file.

-W

2010/4/3 miguel machado <mls.machado at gmail.com>

> hi there,
>
> So like i said, by pre-compiling the rules and loading them in the main
> system i was able to reduce a lot memory usage and i can get better results.
> However, now i've come across a different problem. I just added a fre more
> dozens of rules and the java program responsible for compiling the DRL file
> throws a java heap space error, something like an OutOfMemoryException.
>
> I've read somewhere that dividing the DRL into several files and loading
> e.g. 500 rules at a time might solve it. Is there another approach to this
> problem?
>
> thanks in advance,
> _ miguel
>
>
>
> On Thu, Apr 1, 2010 at 6:12 PM, miguel machado <mls.machado at gmail.com>wrote:
>
>> hi again,
>>
>> 2010/4/1 Edson Tirelli <ed.tirelli at gmail.com>
>>
>>
>>>    Hmm, let me complement Wolfgang's comment:
>>>
>>> > After you have taken the compiled packages from the KB and checked for
>>> errors, the KB has done his duty the KB ****MUST**** go :-)
>>>
>>
>> I agree! But i don't exactly know how to do so... i mean, i call this
>> method which creates the KB from a DRL file and then the kbase and returns
>> the ksession, the KB object declaration scope is just that exact method, and
>> once it reaches 300MB+ in memory, it just stays there... the KB object is no
>> longer in use (or is it?) but memory keeps high.
>>
>> I've tried setting KB to "null" and then invoking the jvm garbage
>> collector, but to no avail. I wish there was a simple way i could just
>> destroy a particular object sigh
>>
>>
>>>
>>>    The above emphasis is mine. KnowledgeBuilder is a higher level object
>>> designed to encapsulate the parsing+compilation steps of resources. It is
>>> **not** designed to be reused and doing so might create inconsistencies. The
>>> memory spike you see when using the kbuilder is due to the java compiler...
>>
>>
>> I understand that, and i'll have that if i must, but the thing is it's not
>> just a spike, it is prolonged throughout execution, it doesn't reduce
>> afterwards.
>>
>>
>>> Drools itself does not do anything fancy in there other than generate
>>> some code (quite inexpensive memory wise) and compile it using either JDT or
>>> JANINO (both quite expensive memory wise, when compared to the other steps).
>>>
>>>
>>>    So, I strongly discourage you keeping the KB around and as mentioned
>>> by Wolfgang, doing so might keep unnecessary objects in memory.
>>>
>>
>> Like i said earlier, it's not that i want to keep KB around, i just can't
>> remove it.
>>
>>
>>>
>>>    Also, just to clarify, deserializing a compiled package means the
>>> compiler will not be called (obviously, as everything is already compiled)
>>> and that is why it should save you memory.
>>>
>>
>> Thanks for clarifying that! I've tested with a separate application to
>> build a compiled file and then load it in the main system and it really
>> makes a difference! it's gone to <100MB wow! However, this was just a
>> proof-of-concept, as i'm not sure how i could apply the same technique to
>> the main standalone application. Do i really have to create a separate
>> process/application just for building/compiling the rules, to make sure the
>> compilation-object-junk doesn't stay in memory along with the rest?
>>
>> Thanks for all the feedback and input so far.
>> _ miguel
>>
>>
>> --
>> "To understand what is recursion you must first understand recursion"
>>
>
>
>
> --
> "To understand what is recursion you must first understand recursion"
>
> _______________________________________________
> 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/20100403/3684a09f/attachment.html