Len Conrad:
> ---------- Original Message ----------------------------------
> From: wie...@porcupine.org (Wietse Venema)
> Date: Fri, 4 Dec 2009 14:13:17 -0500 (EST)
> >I'll mkae a note that postscreen must be used only with low-latency databases
> >such as local files.
>
> the problem postscreen MX pinging the mysql server on the same switch shows:
>
> round-trip min/avg/max/stddev = 0.143/0.227/0.443/0.100 ms
>
> 2 non-problem postscreening MXs pinging from South Carolina to Atlanta show:
>
> round-trip min/avg/max/stddev = 4.613/4.945/5.249/0.205 ms
>
> It's quite confusing to tease where the problem is.
Ping measures the kernel-to-kernel latency. postscreen is affected
by the application-to-application table lookup latency.
Postscreen is a single program that makes a decision on every inbound
connection in real time. Having it talk to a mysql server introduces
huge latency. While the mysql lookup happens, all of postscreen
stalls, meaning it does not take new connections off the input
queue. If this happens often enough, postscreen falls behind and
reports "all ports busy" errors.
For example, if mysql replies in 10ms, then the entire Postfix
system cannot process more than 100 connection requests per second
in total, that's all the connections from zombies and good clients
combined. With such performance, what was meant to be a zombie
killer quickly becomes a self-inflicted DOS.
I'm adding extra checks to postscreen than measure table lookup
delays, and that log warnings when these delays exceed i.e. a couple
milliseconds.
> btw, what does postscreen send to smtp client when postscreen logs this:
>
> egrep -ic "all screening ports busy" /var2/log/maillog
> 5615
It sends a 421 reply.
Wietse
