Ofer Inbar:
> 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.
>
> Changing maxproc did reduce the number of smtpd processes, but I can
"postfix reload" will changethe limit but it does not assissinate
smtpd processes that already run. These processes will terminate
after $max_use/2 connections on average.
> see clearly in the logs that each one of them is still taking several
> incoming messages per second at peak times, and cleanup is placing
> them all in the incoming queue, and the incoming queue gets very big.
> in_flow_delay is apparently not trigerring.
in_flow delay does not prevent the queue from growing. I don't
understand where you get this idea from.
It certainly does not come from the documentation.
> | 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.
>
> 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.
As mentioned in the capitalized text above, the input flow rate
will be allowed to exceed the output flow rate.
The documentation never promised that in_flow_delay will limit the
queue size. Doing that would be an immensely stupid idea.
Wietse
