IMAP/LMTP delays (was Re: IMAPD Mail Delays)

[Mike Eggleston]

On Wed, 05 Sep 2007, Michael D. Sofka might have said:

> On Tuesday 04 September 2007 03:42:05 pm Corey Bobb wrote:
> > The current problem I am having is that I am receiving mail from my outside
> > email relay (postfix) which From what I gather forwards it over the cyrus
> > mail sever however, I can see the postfix server getting the mail . ..but
> > it will take another 30 minutes before the message can actually be viewed
> > in a mail client.
> 
> I've been seeing this as well.  In our case, it's cyrus 2.2.12 with
> sendmail 8.13.1 using MAILER(cyrus2).  Cyrus is run in a murder cluster with a 
> master, two front-end and three back-end servers (one not in use---old, being
> retired, running account creation scripts which need to be moved).
> 
> Sendmail reports: "Deferred: Connection timed out with mail.rpi.edu."
> And, occasionally it reports: "Deferred: Broken pipe."  (mail.rpi.edu is a 
> vip.  Port 25 connections are sent to one of four smtp machines via a Cisco
> CSS director.)
> 
> The 60 minute delay (in our case) was due to the MinQueueAge parameter in
> sendmail.  Once email was deferred to one of the smtp servers, that server 
> continued to queue email for 15 minutes (when the .hoststat is rechecked).
> 
> The queue runners would skip the queued email for 1 hour.   To patch this, I 
> put the local email in a separate queue group, and run sendmail out of cron 
> with MinQueueAge value of 10 minutes.  (Putting a runner on the queue group
> didn't work, since MinQueueAge takes precedence.)
> 
> But, the base problem remains:  For some reason lmtp is returning a 400-level 
> dsn.
> 
> Perhaps related, or not, I have also noticed occasional delays connecting to 
> IMAP.  They tend to cluster around 15 minutes before the hour.  It got 
> particularly bad when students returned last week.
> 
> Google turned up a mention of an error in mupdate which caused it to double 
> free threads when the maximum connections is reached.  Indeed, there were
> numerous "could not start a new worker thread" errors in the cyrus.log file on 
> the murder master.   I doubled mupdate_connections_max to 2048 and the
> problem is reduced.  The delays are still there, but they do not last as long.
> There are still a few 'could not start worker thread' errors.   The process
> involved restarting services on the master, which killed about 800 mupdate
> connections.   Currently there are about 26 mupdate connections.

My /var/log/cyrus.log is empty. How do I raise the log level to see if I'm
also having the same errors?

Mike