Zitat von Scott Adkins <[EMAIL PROTECTED]>: > --On Thursday, June 26, 2003 10:57 PM +0200 [EMAIL PROTECTED] wrote: > > > Zitat von Rob Tanner <[EMAIL PROTECTED]>: > > > >> 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
