Date: Sat, 17 Jul 1999 08:37:21 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Valentin Nechayev" <nx@nn.kiev.ua> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907171537.IAA74714@apollo.backplane.com> References: <199907132229.PAA81360@apollo.backplane.com> <ABe65atWdP@nn.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
:> machine. In this case the overcommit that can occur is with I/O, not
:> swap. As a general performance rule, you have to set MaxDaemonChildren
:> and MaxArticleSize to prevent the overcommit from occuring. This is a
:> function of sendmail, not a function of the kernel.
:
:Sigh. ((c)you) Sendmail can overcommit a machine with right set of
:MaxDaemonChildren, MaxArticleSize, QueueLA & RefuseLA options - I have seen
:such situations. MaxDaemonChildren limits only number of main processes for
:incoming connections (plus queue run processes). For each connection, after
:"main from:" and until accepting message, server process for incoming
:connection forks child which accepts recipient list and letter body. After
:message accepting, that child can fork delivery process. A queue run process
:with "O ForkEachJob=true" option, which is default, can create a delivery
:process for each queue job (in my practice, queue of more than 1000 jobs is
:--
:Netch
Actually this isn't true. QueueLA & RefuseLA tend to be useless options
with sendmail. MaxDaemonChildren, on the otherhand, tends to be a
very useful option.
By running the daemon and the queue separately, and putting the daemon
in queue-only mode, sendmail has virtually no chance of taking down the
machine. Example (assuming a box w/256MB of ram):
sendmail -bd -O MaxDaemonChildren=130 -O DeliveryMode=queue
sendmail -q1m -O MaxDaemonChildren=40 -O MinQueueAge=30m
sendmail -q1m -O MaxDaemonChildren=40 -O MinQueueAge=2h
This is what we do at BEST. Once we began doing things this this way,
our three (continuously loaded) frontend mail machines never bogged down
ever again.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907171537.IAA74714>