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 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. 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). | | 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. | | Specify 0 to disable the feature. Valid delays are 0..10. 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. 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? Also, does in_flow_delay regulate smtpd, or cleanup? Documentation suggests the former, but that aside in QSHAPE_README suggests the latter. (I suppose if it regulated cleanup that could regulate smtpd indirectly, by forcing smtpd processes to wait on cleanup, but I don't know the system well enough to be confident about that). 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. -- Cos
