Too many lmtpd processes running
lst_hoe at kwsoft.de
lst_hoe at kwsoft.de
Mon Jun 30 04:12:04 EDT 2003
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.
More information about the Info-cyrus