OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: smtpd(8) stress behaviour, disconnect on 5XX ???

From: Leandro Santi (lesantigmail.com)
Date: Mon Sep 03 2007 - 15:16:36 CDT


On 9/3/07, Victor Duchovni <Victor.Duchovnimorganstanley.com> wrote:
> On Mon, Sep 03, 2007 at 02:20:25PM -0400, Wietse Venema wrote:
>
> > Leandro Santi:
> > > > High-low watermark solutions alone are too jittery, and moreover
> > > > they are too complex for legacy Postfix releases.
> > >
> > > I'm reluctant to automate decisions based on the
> > > system's load average, because the measure is not
> > > regular across multiple kernel vendors (or different
> > > Linux versions :-), nor it is fair across multiple
> > > hardware configurations.
> >
> > I am talking about Postfix's own load measurement.
>
> Indeed, Wietse is talking about process concurrency, not system load
> and the response is not to defer work (QueueLA/RefuseLA make things work
> when high loads are prolonged)

My experience shows that high load does not
necessarily imply a knocked-out system, not
mentioning the fact that other concurrent
programs (possibly with different compatible
workloads) could be held responsible for it.

It really depends on how you define the measure,
and IMHO it's a poor choice for this purpose (but
please see below).

(And I'm talking from my memory, since I never
came back to Sendmail).

> but to drop connections that hog work
> slots and get *more* work done, this makes sense, as it should drive the
> observed load down given a surge of connection hogs, and not change
> anything for load imposed by a surge of legitimate mail.

Indeed. As Wietse said on a close thread, he
is considering to take action based on process
concurrency, not system load. And because
master is responsible of the concurrency controls,
and process creation, it's in better position for
raising the command-line stress flag.

Leandro