Wietse Venema <[EMAIL PROTECTED]> wrote: > > 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.
I did not get this idea at all. What I expected to see, however, is that when in_flow_delay were trigerred, each smtpd process would not be taking in multiple messages per second. Seeing that they were taking in multiple messages per second (per process ID) when I have in_flow_delay=10s is why I said "in_flow_delay is apparently not trigerring" Is that an accurate understanding? > > | 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. Right. I didn't say that I expected in_flow_delay to prevent input rate from exceeding output rate. However, I expected it to *slow* the input rate when the input rate exceeds the output rate. When I say "doesn't seem to have any effect" I don't mean "doesn't seem to be keeping the input rate below the output rate", rather, I mean "doesn't seem to have ANY EFFECT" (emphasis added). In other words, I expected the conditions I described to be conditions under which in_flow_delay would be triggered, and thus I expected to see its effect (fewer messages per second per smtpd process), and yet I did not see any such effect, which led me to wonder when and how it would be triggerred, and what effect I should actually be looking for. > The documentation never promised that in_flow_delay will limit the > queue size. Doing that would be an immensely stupid idea. Correct. The documentation did say that in_flow_delay would limit the rate of incoming messages when that rate exceeds the "delivery rate", but Viktor explained to me that is incorrect, and I suggested a change to the documentation to match what he explained. I still want to confirm what the observed effect should be: When in_flow_delay is being enforced, does that mean I should see in the log file that each smtpd process is accepting new messages no faster than once every in_flow_delay seconds? That's what I think I should see based on the documentation. -- Cos
