Hi Toby,

Thanks for the answer.  We manage to get a hold of optimize it and we found out that the journaling system kept growing.  After searching on the forum we put the buffered_io_max_pages=16 in the db.conf file.  We re-ran it and the memory was actually growing but finally stopped after awhile and was garbage collected.

One question though, at what point does the buffered_io_max_pages affect a database performance or recovery? 

Thanks,
Philippe
-----Original Message-----
From: Tobias Downer [mailto:toby <at> mckoi.com]
Sent: August 19, 2004 4:48 PM
To: mckoidb <at> mckoi.com
Subject: Re: Memory growth

Hi,

Do you have a heap profiler you can use to inspect the JVM heap?  A heap
profiler will help determine if it's a leak in Mckoi or your own code.

There is some good information on analysis of the JVM heap in the
following link; http://java.sun.com/developer/onlineTraining/Programming/JDCBook/perf3.html

I have found that the 'Heap Analysis Tool' available from that webpage
is a useful tool for tracking down memory leaks.

Toby.

Philippe Bosse wrote:

> Hi,
> 
> Does anyone know what is the regular amount of memory that a
> standalone
> mckoi server runs on for say 10 tables with minimal number of rows (100)
> but with lots of inserts and delete?
> 
> We have a program that does that and the memory growth is quite big,
> started at 20 megs and after 3 days it was up to 200megs while the files
> on disk where no more than 130megs.   That was on Sun.  On windows, it
> was even worse, after 14 hours, the memory was already at 131megs.
> 
> We suspect a memory leak somewhere and that it's our program that is
> causing it but after investigation we are a bit baffled.  We tried the

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