:> 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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
