[rules-users] Measuring Drools Memory Usage

[Roger Tanuatmadja]

Thanks everyone for their answers. Apologies for not providing more details,
but yes I am using Stateful Session and I also took care to call dispose
once I am done with it.

By the way, I am not really looking for memory leakage, a project this size
with many users will have people screaming left and right if there are a ton
of memory leakage. What I am basically looking for is how much memory
(intermediate objects, etc) Drools is using prior to calling dispose. I am
doing this for comparison purposes against a home brew solution created by a
colleague that we are thinking of replacing with Drools.

More inputs will be welcome!!!

Roger



On 7/29/08, Edson Tirelli <tirelli at post.com> wrote:
>
>
>     For Drools 4.0.x we eventually run profiling tools to make sure we got
> not leak. A couple were found and fixed in the past and we are not aware of
> any leak in 4.0.7.
>     It is very important though to make sure that if you are using stateful
> sessions, you call dispose() on the session after using it. Otherwise,
> drools will hold resources internally (since it is a stateful session).
>
>     []s
>     Edson
>
> 2008/7/29 Ingomar Otter <iotter at mac.com>
>
>> We used two approaches to double check results.
>> At first we used an approach similiar to what you haved described. Please
>> note that (depneding on platfom) freeMemory is not byte- exact). Wo you
>> won't see little changes.
>> Also, if you were using stateless sessions the result you have seen may be
>> correct.
>>
>> Out other approach was to seriazie that parts we're instrested in (and
>> assume that real memory usage is just an small factor to be applied to the
>> result we go.
>> We then compared the two results and they agreed on the order of magnitude
>> which was what were looking for.
>> However we were primarily looking at Rulebase sizes, not WM memory
>> consumption - which for the application we are currently are working on is
>> neglegctible.
>>
>> >Has anyone attempted to measure the incremental memory usage of using
>> >Drools
>>
>> Do you expect an incremental memory usage (aka memory leak) using Drools?
>> I don't  ;-)
>> You may want to run your use-case let's say 100.000 times to easiert to
>> measure results.
>>
>> --I
>>
>>
>>
>>
>>
>> Am 29.07.2008 um 03:11 schrieb Roger Tanuatmadja:
>>
>>   Hi,
>>>
>>> Has anyone attempted to measure the incremental memory usage of using
>>> Drools? Anyone cares to share their methodology?
>>>
>>> I am currently following the following methodology:
>>> 1. Prevent garbage collection from happening by using large Xms Xmx
>>> (1024m
>>> in my case), a NewRatio of 2 (I am sure other sizes will work as well)
>>> and
>>> verbogegc enabled to confirm that no garbage collection is happening.
>>> 2. Use Runtime.freeMemory before and after fireAllRules and measuring the
>>> difference.
>>>
>>> The problem with my methods so far has been that after a positive memory
>>> usage (indicating you are using memory), subsequent use case (the same
>>> one)
>>> incurs zero memory usage which is very strange.
>>>
>>> So I guess my question is 2 fold: anyone care to share their methodology,
>>> and can anyone see what's wrong with mine?
>>>
>>> Thanks,
>>>
>>> Roger
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss, a division of Red Hat @ www.jboss.com
>
>
> _______________________________________________
> 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/20080729/bb491eca/attachment.html