Hi Mattijs, Am Montag, den 08.08.2005, 14:56 +0200 schrieb Matthijs van der Klip: ... > Linux 2.4 and 2.6 kernels have a setting for their overcommitment > behaviour under /proc/sys/vm/overcommit_memory. The different settings > are: ... > For now I've set this to '2' which means the kernel won't overcommit > anymore, just like any other proper OS... ;-)
I am running with this setting too since you pointed me to it some time ago. I do not notice a difference though. Also it does not fix my memory leak. A 'fillmem' like tool can however reclaim the memory. Unfortunately it does also reclaim the space hold by the file system buffers. On my development system this well-filled file system buffer space is the most valuable resource. :( My experiments with the 'fillmem' like tool showed that just allocating memory does not show up in the 'Active' memory value. Only initializing the allocated memory does the trick. This means that the memory leak results from pages which have been in real use. > > One final question though: my experience with InnoDB is that it really, > really likes to be able to fit all of it's data and keys into the buffer > pool. This would limit the maximum size of my database to roughly 4GB in > this case, correct? This is in a website hosting environment where the > database is hit with about 1000 queries/s (mixed read/write). I do not believe this. Perhaps you mean that the performance degrades if the database is bigger than the cache. I this case you are right. But I can't think of any way to get around it. If you mean something else, I can't help you much with InnoDB. Please start a new thread with good "Subject:" on the MySQL mailing list and/or on the InnoDB forum (forums.mysql.com). Regards, Ingo -- Ingo Strüwing, Senior Software Developer MySQL AB, www.mysql.com Office: +49 30 43672407 Are you MySQL certified? www.mysql.com/certification -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
