On Wed, Oct 22, 2008 at 01:58:24PM -0400, Ofer Inbar wrote:
> On some fallback relay servers that receive legitimate incoming mail
> (relayed from the first-pass MTAs) much faster than they can process
> it at times, I tried slowing things down using in_flow_delay.
>
> I set in_flow_delay = 10s, and decreased maxproc for smtpd in master.conf.
You are expecting too much from in_flow_delay.
> Documentation says:
>
> | in_flow_delay (default: 1s)
> | Time to pause before accepting a new message, when the message arrival
> | rate exceeds the message delivery rate. This feature is turned on by
> | default (it's disabled on SCO UNIX due to an SCO bug).
This is a simplified description, the actual trigger is when the queue
manager is not moving messages into the active queue as quickly as they
arrive in the incoming queue, either because the active queue is full,
or the disk is saturated and the queue manager is under-scheduled.
The connection to "delivery rate" is indirect. If input exceeds output for
a sufficiently long time, the active queue will fill, and in_flow_delay
will start to activate.
Also, in_flow_delay applies *only* to the portion of the input messages
that exceeds the queue manager's ability to absorb new mail, per unit
time, if N messages are delivered, new space is made in the active queue
and N new messages are moved from incoming to active, N new messages
will be accepted that are not subject to the in_flow_delay.
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).
> |
> | With the default 100 SMTP server process limit, "in_flow_delay = 1s"
> | limits the mail inflow to 100 messages per second above the number of
> | messages delivered per second.
ABOVE the messages delivered per-second, ONCE the active queue is full,
or disk I/O is saturated and the queue manager is starved...
> Messages are definitely coming in much faster than are being delivered
> (or bounced or deferred) at peak times, yet in_flow_delay doesn't seem
> to have any effect.
It is a very weak control, mostly intended to deal with a single
threaded run-away SMTP submission application, ...
> Someone on the IRC channel suggested that in_flow_delay is actually
> only enforced when the active queue is full. Based on that hint, I
> searched postfix.org and found this in the QSHAPE_README:
>
> "Note, that once the active queue is full, the cleanup service will
> attempt to slow down message injection by pausing $in_flow_delay for
> each message."
>
> Which of these is supposed to be right?
> What actually is supposed to trigger in_flow_delay?
The queue manager not keeping up and "incoming" growing. If "incoming"
is nearly empty, and "active" is growing, there is no in_flow_delay
even if the delivery rate is below inflow.
> Also, does in_flow_delay regulate smtpd, or cleanup?
cleanup.
> I haven't yet reconfigured and restarted the server in question
> because it's got a very large backlog of mail at the moment and
> I don't want to delay it until I know what I'm doing so for. It
> has a pretty large active queue that has not filled.
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
empty almost all the time).
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[EMAIL PROTECTED]>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
