imapd mem exhausted

[Scott Adkins]

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 
<prlw1 at newn.cam.ac.uk> 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:adkinss at ohio.edu
        ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
 +-----------------------------------------------------------------------+
     PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 231 bytes
Desc: not available
Url : https://lists.andrew.cmu.edu/mailman/private/info-cyrus/attachments/20030924/e7e7576f/attachment.bin