Ahh, this is very very helpful, thank you.

The problem on the fallback relays is indeed that they're disk I/O
bound, so "incoming" grows too quickly and qmgr can't get messages
into active fast enough.

If I understand you correctly, in_flow_delay will limit the *growth
rate* of the incoming queue, that is, it limits the difference between
messages coming in to "incoming" and messages leaving "incoming".

Also "delivery" or "delivery rate" are not relevant (except indirectly
when the active queue is full and "delivery" - or deferral, for that
matter - is what limits the rate of messages leaving "incoming").

Do I have that right?

If so, I'd rewrite the first paragraph of the in_flow-delay section in
postconf(5) to:

| Time cleanup pauses before accepting a new message, when the message
| arrival rate exceeds the rate at which messages are being moved out
| of the incoming queue by qmgr. This feature is turned on by default
| (it's disabled on SCO UNIX due to an SCO bug).


Victor Duchovni <[EMAIL PROTECTED]> wrote:
> So the in_flow_delay control, caps the msgs/sec *overshoot* PER delivery
> channel. If you have 10 MTAs sending mail, each using 20 connections,
> even with in_flow_delay = 10s, you get 20 msgs/sec more input than the
> queue manager is able to absorb (but at least not 200 or 2000 msgs/sec).

Regardless of number of MTAs, each "delivery channel" requires an
smtpd process on the fallback, right?  So I can limit the number of
simultaneous delivery channels using the maxproc setting on the smtpd
line in master.cf, and limit the growth rate of the incoming queue to:
  [ smtpd maxproc / in_flow_delay ] messages per second

IOW, if maxproc = 10, in_flow_delay = 10s,
then "incoming" can't grow faster than 1 message per second.

> > Also, does in_flow_delay regulate smtpd, or cleanup?
> 
> cleanup.

... and cleanup keeps a separate in_flow_delay timer for each smtpd?

> If the active is never full, and disk I/O is adequate, there will be
> no in_flow_delay (evidenced by the "incoming" queue being nearly

Disk I/O is not adequate :/   (dealing with that separately)
  -- Cos

Reply via email to