Too many lmtpd processes running

[lst_hoe at kwsoft.de]

Zitat von Scott Adkins <adkinss at ohio.edu>:

> --On Thursday, June 26, 2003 10:57 PM +0200 lst_hoe at kwsoft.de wrote:
> 
> > Zitat von Rob Tanner <rtanner+cyrus at linfield.edu>:
> >
> >> Hi,
> >>
> >> I've just brought up cyrus imap v2.1.13 and I've noticed that there are
> >> over lmtpd processes running.  Isn't that a bit excessive?  It's starting
> >> to bog down the server.
> >>
> >
> > Limit the number of lmtp clients used by your MTA (Postfix/Sendmail ...)
> > to some value your server can stand. Most of the time 2 are enough.
> >
> > Should go to the FAQ i guess.
> 
> I don't think I can agree with your answer :-)  It really depends on the
> system and how much mail you pump through it.  It also depdns on how you
> do your email delivery.  For instance, in our sendmail configuration, we
> queue all incoming mail and use cron jobs to fire off queue runners to
> process the various queues we have, with some queues running more often
> than others.  If we have 30 sendmail queue runners processing our Cyrus
> queue, then we should expect to see 30 LMTP process as well, one for each
> of the queue runners that could feed them mail.

Don´t know about sendmail but the point is if you have one Cyrus partition
massive parallel deliver gain nothing because all the lmtp fight for the same
(rare) I/O resource and you get in trouble with locking at some point.
This is true for MTA local/ MDA local scenario.
If you deliver from slow MTA gateways (virusscanning) over network to one fast
Cyrus MDA by lmtp running a lot of "lmtpd" makes sense.

> As for the original question, you didn't actually state how many LMTP
> processes you are seeing.  We typically don't worry about it as long as
> we are under 100 processes... when we go over that though, we start
> looking at the processes (with LSOF) to see if there are a lot of procs
> stuck on a single file (usually a cyrus.header file of a particular user).
> This is a lock problem that we have been fighting with for a long time
> (we are using 2.0.16) and end up restarting the server to fix it.

You can fix this by running a lower number of lmtp-clients :-)

> So, my suggestion is to look at the LMTP process you have, see if a lot
> of them are blocked doing nothing (i.e. probably waiting for a file to
> unlock).  If they all look busy, then I wouldn't worry about it.
> 
> Scott

Regards

Andreas