Memory leak/CPU load (Was: servername not honored in imapd.c?)

[Simon Matter]

> Quoting Simon Matter <simon.matter at ch.sauter-bc.com>:
>
>> Unfortunately I also found a server having problem with it. That's why I
>> have removed the new package again.
>> In my case one imapd process was in a loop consuming gigabytes of memory
>> until it was killed by the kernel. This happened again and again.
>> I attached an strace to the process but lost it's output for some stupid
>> reason.
>> Maybe I can reproduce it later and provide some more information, or Ken
>> alreasy knows what the problem is.
>
> Hi Simon,
>
> I'm having similar problem with your 2.3.1-2 RPM package too.  The
> mupdate process starts consuming hundreds megabytes of memory after
> some time.  I restarted it yesterday afternoon, and found it fluctating
> between 180 and 370 megabytes this morning (according to top).
> Attaching with strace hasn't showed it doing anything (waiting in
> accept, more or less).  The load average on the system was sky high
> too.  This was part of my testing setup.  Three users (including cyrus
> admin), two backends, two frontends, completely idle.  No way it needed
> to grow that large.
>
> Seems that CPU is spending most of time in system calls (according to
> top and vmstat):
>
> $ vmstat 10
> procs -----------memory---------- ---swap-- -----io---- --system--
> ----cpu----
> r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id
> wa
> 1  0      0  48696  78436 282840    0    0     5     9  347   141  7 70 23
>  0
> 2  0      0  48680  78440 282844    0    0     0    16 1016  1336  7 66 27
>  0
> 1  0      0  48760  78440 282844    0    0     0     1 1012  1825  6 85  9
>  0
> ...
>
> $ top -u cyrus
> top - 08:11:56 up 17:58,  1 user,  load average: 10.51, 11.68, 12.17
> Tasks:  64 total,   1 running,  63 sleeping,   0 stopped,   0 zombie
> Cpu(s):  8.5% us, 84.3% sy,  0.0% ni,  6.7% id,  0.0% wa,  0.4% hi,  0.2%
> si
> Mem:    515704k total,   468552k used,    47152k free,    78548k buffers
> Swap:  2064376k total,        0k used,  2064376k free,   284128k cached
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 2007 cyrus     16   0 29860 1556 1276 S  0.3  0.3   0:11.70 idled
> 1983 cyrus     16   0  5280 1388 1084 S  0.0  0.3   0:03.55 cyrus-master
> 2033 cyrus     16   0  180m 2488 1856 S  0.0  0.5   0:00.29 mupdate
> 2035 cyrus     15   0 31140 2044 1660 S  0.0  0.4   0:00.07 imapd
> 2036 cyrus     15   0 30632 2016 1636 S  0.0  0.4   0:00.12 pop3d
> ...
>
> Attaching with strace to mupdate process showed it was simply waiting
> in accept.  Nothing special:
>
> # strace -p 2033
> Process 2033 attached - interrupt to quit
> accept(4,
>
> I also attempted to attach to it with debugger, but got "ptrace:
> Operation not permitted.".

I'm not using murder, so I don't know problems with mupdate. What I can
say is that I only had problems with the 2.3.1-3 package which included
patches from CVS. However I'm now running the 2.3.1-2 package on several
quite large production servers without any problems. Maybe someone else
using murder could try to reproduce you problems.

Simon