Re: [rules-users] drools expert: memory issues

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(a)gmail.com&gt; > 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(a)gmail.com&gt;wrote: > >> hi again, >> >> 2010/4/1 Edson Tirelli <ed.tirelli(a)gmail.com&gt; >> >> >>> 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users