Philippe Bosse | 2 Sep 2004 12:46

RE: Memory growth

Hi Toby,

After letting the test run until the computer was out of memory(somehow optimizeit uses a LOT of memory compare to the rest of the system).  Our db is small(6 tables but only one is intensily used) but we do a lot of insert, update and delete.  In fact for this particular test we have reduce the resync update time to 20 sec but in real life it will be closer to every minute.  McKoi perform amazingly well, the journaling system was kept between 1100 to 1600 instances(compare to the 40000+ instance of McKoi 1.0.2) with the default value of McKoi 1.0.3.  Heap size was stable at about 16 megs overall. 

Thanks for your help,
Philippe

-----Original Message-----
From: Tobias Downer [mailto:toby <at> mckoi.com]
Sent: August 26, 2004 5:33 PM
To: mckoidb <at> mckoi.com
Subject: Re: Memory growth


Are you performing these tests on a small test application?  Your best
bet would be to profile the long running application that you mention is
claiming 140 MB after 14 hours.  That way you will be able to determine
for sure if there is a leak in Mckoi code or your own code.  Keep in
mind that it's not unusual for Java to claim a lot of memory whether it
is actually utilizing it all or not.  It seems the implementors of Java
for Windows have decided the best approach is to claim a lot of memory
and let the Windows virtual memory manager manage the utilization of the
main system memory.  When testing your application's memory use, it's a
good idea to use the 'Runtime.getRuntime().freeMemory()' and
'totalMemory()' functions.

The type of information I would be interested in is the amount of memory
the journal objects are using relative to the rest of the system, etc.
Whether you think there is a leak in Mckoi and what objects that are
leaking.  Note that by default, the journal cache is setup to use about
2 MB of the heap.  The 'buffered_io_max_pages' property is 256 by
default, and increasing this value will cause Mckoi to cache more pages
in memory.  Each object has a 8192 byte[] buffer.

Toby.

Philippe Bosse wrote:

> Hi Toby,
>
> We'll run it and send you the results. Is there anything in particular
> that would be of particular interest to you?  We did notice that the
> journaling system was still increasing but more slowly since there was
> some garbage collection done.
>
> Regards,
> Philippe



---------------------------------------------------------------
Mckoi SQL Database mailing list  http://www.mckoi.com/database/ To unsubscribe, send a message to mckoidb-unsubscribe <at> mckoi.com


Gmane