From: Andrzej Adam Filip on
per(a)hedeland.org (Per Hedeland) wrote:
> In article <6os172tpw4+A5E(a)susan.huge.strangled.net> Andrzej Adam Filip <anfi(a)onet.eu> writes:
>>per(a)hedeland.org (Per Hedeland) wrote:
>>> In article <66f9a$4becb619$d1d97a75$29567(a)PRIMUS.CA> "David F. Skoll"
>>> <dfs(a)roaringpenguin.com> writes:
>>>>RICCARDO wrote:
>>>>
>>>>> #O QueueLA=8
>>>>> #O RefuseLA=12
>>>>> #O DelayLA=0
>>>>
>>>>The Sendmail defaults are utterly inappropriate for Linux. I use:
>>>>
>>>>O QueueLA=1000
>>>>O RefuseLA=500
>>>>
>>>>Or in .mc language:
>>>>
>>>>define(`confQUEUE_LA',`1000')dnl
>>>>define(`confREFUSE_LA',`500')dnl
>>>>
>>>>In other words, I don't want sendmail to stop, regardless of load
>>>>average. And I *certainly* don't want it queueing, but not
>>>>delivering, if the load average is high.
>>>
>>> This is an important point - whether Linux or not, and regardless of the
>>> absolute size of the numbers, on a dedicated mail server you always want
>>> to have QueueLA higher than RefuseLA. The defaults are from an ancient
>>> time when processing mail was typically just one of many tasks on a
>>> general-purpose server, and you didn't want it to impact more
>>> "interactive" functions at times of high load. If the load is *caused*
>>> by mail processing, having QueueLA lower than RefuseLA will just make
>>> things worse.
>>
>>You are most likely right in *most* cases but I would not dare such
>>"too simple statement" - there are exceptions (e.g. with "costly" local
>>mailer forking one process per recipient under multiple recipient load).
>
> You avoid that cost whether you queue or refuse - but as long as you
> keep queueing in an overload situation, you keep causing load from that
> processing, and keep building up future load that will hit you when you
> start processing the huge queue - if you ever get below QueueLA, that
> is.
>
> As you just quoted Nick's book in another post, go read what he has to
> say on the subject... (and it wasn't new wisdom when he wrote it).

Nick [unlike you ;-)] used phrase "on *almost all* *busy* email servers"
when issuing "warning+" against using QueueLA lower than RefuseLA.
Nick also explained *why*: such servers can become very easily limited
by queue (disk) IO.

I also *very easily* agree that QueueLA may be a good idea when dealing
with "short" (peak) overload on server ready for very high peak load
(almost "idle" for most of the time) but it may be a "*horrible*
disaster in making" when dealing with *LONG* "overloads".

IMHO server with 700 messages per day is unlikely to be IO bound,
it seems to be CPU bond by "in SMTP session checks".

I have also seen/heard about installation using two stage AV/AS checks.
"Simple" checks in SMTP session (with in SMTP session refusal to take
over responsibility for delivery) and "very detailed" checks from queue.
In such configurations QueueLA makes sense to deal with peak load.

BTW IMHO It would be a *great* idea to make QueueLA dependent on number
of queued messages.

URL(s):
http://www.jetcafe.org/~npc/book/sendmail/
http://www.amazon.com/sendmail-Performance-Tuning-Nick-Christenson/dp/0321115708

--
[pl>en Andrew] Andrzej Adam Filip : anfi(a)onet.eu : Andrzej.Filip(a)gmail.com
http://open-sendmail.sourceforge.net/ http://anfi.homeunix.org/
Just don't make the '9' format pack/unpack numbers... :-)
-- Larry Wall in <199710091434.HAA00838(a)wall.org>