cpu and cyrus

[Bron Gondwana]

On Wed, Aug 31, 2011 at 11:36:44AM -0700, Maria McKinley wrote:
> On 8/31/11 10:56 AM, Bron Gondwana wrote:
> >On Wed, Aug 31, 2011 at 10:33:14AM -0700, Maria McKinley wrote:
> >>Hi there,
> >>
> >>I am having an issue with cyrus processes growing to use all of my cpus,
> >>at which point I have to restart cyrus, because all other services on my
> >>mail server grind to a halt. Below is my config file. Any ideas what may
> >>be causing this? I noticed this behavior after the last cyrus update. I
> >>am currently using cyrus 2.2.13-19+squeeze1, debian. I think my
> >>processor should be plenty powerful for the mail load I handle.
> >>
> >
> >Which processes in particular?  Cyrus 2.2 isn't supported any more,
> >so we're unlikely to be providing any fixes if you've hit a bug that
> >doesn't exist in more recent versions.
> >
> >Regards,
> >
> >Bron.
> 
> 
> So annoying that the stable release of debian isn't supported
> anymore. It seems like if you wait so long to release the stable
> version that it isn't supported anymore, it sort of defeats the
> purpose.

Debian have been staying at 2.2 rather than moving up to 2.3 through
two stable releases now.  There is a limit to how long you can hold
on to the past.  Cyrus 2.3.0 was released in December 2005.

> Anyway, here is an example of some processes that are getting big:
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 
> 24328 cyrus     20   0  147m 6236 5004 R 27.4  0.2  22:07.21 imapd
> 
> 27549 cyrus     20   0  147m 6512 5116 R 27.4  0.2 155:41.26 imapd
> 
> 30097 cyrus     20   0  147m 6280 5052 R 27.1  0.2  93:44.08 imapd
> 
> 
> Unfortunately I can't tell you anymore about these processes, since
> they are just cut and pasted from a terminal where I checked top
> before restarting cyrus, and cyrus has not regrown yet.

Ok - next time it goes crazy can you pick one up with gdb and get
a backtrace?

gdb $cyrusbinpath/imapd $pid

and then when you get the prompt:

bt

and maybe also:

p imapd_in

which will give us the command that's running.

There are various bugs back in the 2.2 series which could cause
an infinite loop - and the most interesting bit is working out
which corrupt file is causing the problem.

Bron.