Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.Hawaii.Edu!news.uoregon.edu!news.u.washington.edu!worldnet.att.net!uunet!in1.uu.net!192.203.206.1!news.wonderworks.com!u-sure-kin-mambo From: kyle_jones@wonderworks.com (Kyle Jones) Newsgroups: comp.mail.sendmail,comp.mail.smail,comp.unix.bsd.freebsd.misc Subject: Re: Sendmail vs. Smail... Date: 9 Dec 1996 18:40:31 -0500 Organization: Wonderworks Inc. Lines: 45 Sender: kyle@crystal.WonderWorks.com Message-ID: <58i81f$ajf@crystal.WonderWorks.COM> References: <57tf61$gq7@raven.eva.net> <589jsm$o2v@ezekiel.eunet.ie> <58be63$eu@stdismas.bogon.com> <58i45b$apn@nntp1.best.com> NNTP-Posting-Host: crystal.wonderworks.com Xref: euryale.cc.adfa.oz.au comp.mail.sendmail:34977 comp.mail.smail:2674 comp.unix.bsd.freebsd.misc:32338 Matt Dillon <dillon@flea.best.net> wrote: > [...] > * Turn ON ForkEachJob ... you don't really have a choice. > If you don't, the sendmail's running the queue can build > to five times their normal RSS and effectively run the > machine out of memory. Unfortunately, turning > ForkEachJob off also blows the connection cache... oh > well. Maybe a later version of sendmail will allow one > to specify how many jobs per fork one can run :-). You can combat this growth with smaller queues. Take fifteen thousand queued message and spread them over 150 directories and queue runs aren't so bad. The sendmail process runs out of jobs before it gets really fat. Limiting queue size is a good idea anyway because of the linear directory searches combined with directory update locking that can keep open() and unlink() blocked for a long time. > There's a story here: We once received a mail bomb where > the bomber sent the entire message body as a header. > There were only about 50 of these messages in the mail > queue, but they caused the sendmail's running the queue > to grow to about 8 MBytes RSS. The machine, with 128 MB > of ram, started to swap! Holy cow! Groovy. sendmail used to crash when faced with such headers, freeing memory in the process. Sometimes sendmail bugs are you friends. :) > I've also tried to turn off ForkEachJob with the latest > 8.8.4 release... it doesn't work. The sendmail's still > build up to around a 3 MB RSS and kill the machine. You might be able to get by with fewer queue run processes if you run some of them with drastically smaller connection timeout values. If a host doesn't respond in 15 seconds. it probably isn't going to respond at all. Instead of (typically) waiting 60 seconds, give up and move on. A complete pass of the queue takes much less time, and responsive hosts are rewarded by getting their mail delivered sooner. The sluggish hosts will be serviced eventually by the queue runs that use the RFC 1123 minimum timeouts. You should not let the fast queue runnners write into the persistent host status cache, or slow hosts will never get their mail.