What version of Cyrus are you using? We are using 2.2b1 here, and are experiencing something similar with memory issues for IMAP. I brought up the discussion a few weeks ago about it and it was characterized as some kind of mmap() weirdness on our Tru64 platform, which I don't really think is the case.
I will look in our logs to see if we are seeing a similar issue with a lot of accepted connections as you are.
My experiences are as follows with the problem:
1) It seems that the RSS footprint of the process increases when a user
makes a connection (from observation). 2) Most of the time, we may see a process jump up to 26 or 27MB in size
(and lately, we are now seeing them jump up to 30-32MB in size), but
typically go back down to several hundred KB shortly thereafter. If
the system starts to slow down for whatever reason, the time for a
process to shrink increases, and we have more processes at the bigger
RSS size and run the risk of exhausting memory and swap. 3) The problem was characterized as an mmap() problem on Tru64 because
our mailboxes.db file is about 27MB in size. However, we are seeing
the sizes jump to 30-32MB in size, and our mailboxes.db file is still
only about 27MB in size. *shrugs* 4) Restarting the Cyrus server has a dramatic effect on memory usage by
putting all the processes back at the base several hundred KB size.
It takes quite a while before we see the issue #2 become a problem
again (even on a busy server).Anyways, I have been looking at this problem over that last several days and my gut feeling has been leaning towards the on-connection route... which certainly jives with your message below...
Scott
--On Wednesday, September 24, 2003 12:02 PM +0100 Patrick Welche <[EMAIL PROTECTED]> wrote:
Sep 24 09:50:30 imp imap[2030]: executed Sep 24 09:50:30 imp imapd[2030]: accepted connection Sep 24 09:50:47 imp imapd[2030]: accepted connection .... Sep 24 09:51:15 imp imapd[2030]: accepted connection .... Sep 24 10:26:23 imp imapd[2030]: Fatal error: Virtual memory exhausted
That was then a reasonably long lasting connection that was just doing CREATE followed by stacks of APPEND non-stop. There was only me as a user (only 1 imapd). I suppose that is rather different to the usual usage pattern of lots of connections doing a few things. After a few minutes I see:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 19526 cyrus 2 0 35M 37M select 0:10 0.93% 0.93% imapd
Is this a memory leak, or are the messages being stored in memory ie., it's meant to happen?
Is there a simple way of telling master to give imapd some more memory when it forks?
Cheers,
Patrick
-- +-----------------------------------------------------------------------+ Scott W. Adkins http://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +-----------------------------------------------------------------------+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
pgp00000.pgp
Description: PGP signature
