Hi all, Thanks for your tips. Indeed I had some redundancy in my rule definitions, now i've removed them and it has reduced memory usage a little bit. Any other suggestions are welcome :)
thanks again. _ miguel 2010/3/31 Wolfgang Laun <wolfgang.l...@gmail.com> > I can only offer a few hints: > > Factor out all code that can be done in one of the called methods, e.g., in > resetSource( ..., Arrays.asList($value1)); > Here, the Arrays.asList() should be done in resetSource(). > > Avoid multiple bindings. If you call > resetSource( $source,....) > or > checkMayReset( $source,...) > the additional parameters $object and $CI can be retrieved within > resetSource(). > > The funny String literals are the one thing that are strikingly different > from what you usually see in rules. String literals cost for each occurrence > unless you intern strings using javal.lang.String.intern(). (I haven't tried > whether Drools would accept that instead.) But calculating the raw cost as > (46 chars*2 bytes/char+20 bytes)*10 times * 700 rule triples only accounts > for 0.8MB, so this alone isn't the culprit. > > -W > > > 2010/3/31 Miguel Machado <mls.mach...@gmail.com> > > Hi, thanks for answering so quickly. >> >> My ±2100 rules are grouped in 700 groups of 3 drools rules each, which are >> related to the same type of event i want to generate, like the following: >> >> >> rule "event1 reset" no-loop salience 9 activation-group "event1_group" >> lock-on-active agenda-group "a3ce4a97-13d8-4bec-a9ab-5625fcd0f105" >> when >> $source : SourceBO( >> ciUUID == "3938adc4-246d-43f3-b606-da4c3f09d49b", >> $object : object, >> $CI : ciUUID, >> $sourceUUID : sourceUUID) >> $value1 : SourceValueBO ( valueName == "VALUE1", numericValue < 90 ) >> eval (checkMayReset($source, "fb95632f-fac9-4359-9d7c-dc38d3e48e20", $CI, >> $object)) >> then >> modify ($value1) { setConditionValue(90) }; >> resetSource($source, "fb95632f-fac9-4359-9d7c-dc38d3e48e20", $CI, $object, >> "event_version", "event_text", Arrays.asList($value1)); >> end >> >> rule "event1 fire" no-loop salience 6 activation-group >> "event1_group" lock-on-active agenda-group >> "a3ce4a97-13d8-4bec-a9ab-5625fcd0f105" >> when >> $source : SourceBO( >> ciUUID == "3938adc4-246d-43f3-b606-da4c3f09d49b", >> $object : object, >> $CI : ciUUID, >> $sourceUUID : sourceUUID ) >> $value1: SourceValueBO ( valueName == "VALUE1", numericValue > 90 ) >> then >> modify ($value1) { setConditionValue(90) }; >> FireCondition $start = new FireCondition("repeat", 0, "duration", "0s"); >> addToActivationQueue($source, "fb95632f-fac9-4359-9d7c-dc38d3e48e20", >> $CI, $object, $start, null, "event_version", "event_text", >> Arrays.asList($value1)); >> retract($source); >> end >> >> rule "event1 clear" no-loop salience 5 activation-group "event1_group" >> lock-on-active agenda-group "a3ce4a97-13d8-4bec-a9ab-5625fcd0f105" >> when >> $source : SourceBO( >> ciUUID == "3938adc4-246d-43f3-b606-da4c3f09d49b", >> $object : object, >> $CI : ciUUID, >> $sourceUUID : sourceUUID) >> then >> clearActivationQueue($source, "fb95632f-fac9-4359-9d7c-dc38d3e48e20", $CI, >> $object); >> end >> >> So, i'l try to explain briefly: >> * The reset rule evaluates 2 patterns and one condition in a static method >> available via "import function". As a consequence, it modifies the >> SourceValueBO object and call's the reset function which is another static >> method. >> * The fire rule is very similar to the reset rule, the difference being >> that the value threshold is different (usually the opposite) >> * The clear rule is like an "else" to the two above. I want it to fire in >> case it didn't fall for either one of reset and fire rules. >> >> The activation group assures that only one of these rules is fired each >> time i call session.fireAllRules(). And the agenda-group allows me to stack >> some rules above others, according to the type of facts i insert into >> memory. >> Everything seems in place and it works as intended, the thing is i might >> be dealing with *lots* of events (event1, event2, etc...) and lots of >> different UUID's which results in a very large DRL file. For instance, if i >> have 700 events (event1, event ...event700), i get 2100 drools rules (event1 >> reset, event1 fire, event1 clear ... event700 reset, event700 fire, event700 >> clear) and over 300MB in consumed memory. >> >> Perhaps if i took another approach? or some performance tunning, i don't >> know. Where can i improve this memory hogging? >> _ miguel >> >> >> >> >> On 31 Mar 2010, at 06:53, Wolfgang Laun wrote: >> >> The figures (+300MB) you quote are frightening, and it would be *very* >> interesting to learn what sort of rules causes this excessive amount >> of heap usage. Could you post typical patterns - if they are >> generated, there ought to be - and guestimates w.r,t, their relative >> frequencies? >> >> -W >> >> >> On 3/30/10, miguel machado <mls.mach...@gmail.com> wrote: >> >> hi again, >> >> >> On 30 Mar 2010, at 18:32, Edson Tirelli <ed.tire...@gmail.com> wrote: >> >> >> I am not sure I understand what you are doing when you say: >> >> >> Every X seconds I collect the available facts and call fireAllRules() + >> >> dispose(), **always within the same session**. >> >> (emphasis is mine) >> >> >> i meant that i keep using the same object, i just create one stateful >> >> session throughout the program execution. >> >> >> Compilation indeed uses more memory, but you can compile once and reuse >> >> the kbase. >> >> >> >> exactly, i'm doing that, but it's a +700 rule file and its taking too much >> >> memory. Is there anything i can do to push it down a little bit? i >> wouldn't >> >> mind slowing it down to reduce memory footprint. >> >> >> Also, if you are calling dispose, I guess you are running stateful >> sessions. >> >> Maybe you can give us a more detailed description of your >> >> session/data/application lifecycle? >> >> >> Sure, i'll try. So i have this thread which initializes by reading the >> rule >> >> base from a drl file. It then creates a stateful session from it and >> enters >> >> a lifecycle in which it goes to sleep and only when some other thread >> wakes >> >> it up, it collects and inserts some facts (usually 2,3 or 4..) into the >> >> session and fire all rules. It's basically this. What i'm very concerned >> >> about is the amount of RAM memory the whole program is consuming. I must >> >> find a way to reduce some of it, because the rule file is being prepared >> by >> >> an external program and i have no control over the number of rules i might >> >> get. If i test it with a little over 700 rules, it reaches +300Mb which is >> a >> >> lot. >> >> >> Maybe the rules are too complex? Shall i try to make them simpler (how)? >> >> what are the big memory hogs when it comes to loading a DRL file to the >> >> knowledge base? From what i've been testing, it doesn't even matter which >> >> rules you will actually need, it just loads the entire DRL file with no >> >> respect to the future activations, am i right? Is there any other aspect i >> >> should take in mind or maybe other approach? >> >> >> _ miguel >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- "To understand what is recursion you must first understand recursion"
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users