Date: Fri, 19 Oct 2001 11:03:23 -0400 From: Scott Adkins <[EMAIL PROTECTED]>
Actually, we have made the same obvservation here after upgrading to 2.0.16 from 1.5.14. Many of our imap processes climb up to 14MB in size (though, I have never seen one bigger than that) and stay there. One of my guesses as to why that is the case is based on the fact that the imapd processes now stick around for multiple connections. I wonder if the process is not properly freeing up memory after one user disconnects and before the next user disconnects. I also don't know how much of this is due to the way the OS (Tru64) manages process memory. Most operating systems don't release memory from a process after free() is called, so process sizes only climb---they never drop. However, what's far more important is the working set size of each process. Any memory that is allocated (by the OS to a process) but never used can be paged out and doesn't really cause any problems, with large enough paging disks. The thing to avoid is having a working set size of all processes exceed main memory. The 14 MB number you are seeing may also be a side effect of the shared memory that Berkeley db is using. Are you certain that number represents 14 MB of _private_ memory in core? This is on my list of things to do to determine why the resident memory footprint is so large. It is definitely larger than the older version, and with several thousand imap servers running, this is a lot of memory. Again, what is the _incremental_ cost of an additional imapd process? I also don't remember whether Tru64 has good mmap() semantics or not. Does Cyrus's configure complain about mmap()? Larry
