On 2/22/2012 12:33 PM, Wietse Venema wrote: > Alex: >> Hi, >> >> I have a postfix-2.8.7 system with fedora15 and amavisd-new-2.6.6. >> Lately I have been experiencing significant delays before receiving >> the initial postfix 220 greeting from all remote hosts. I've verified > > What is the output from: > > grep warning: /var/log/maillog > > Then you may want to read this webpage: > > http://www.postfix.org/STRESS_README.html
You've already got a default_process_limit of 200 which should be more than plenty for a very large inbound stream, assuming everything else is in order. In addition to the recommendations in the STRESS_README WRT decreasing time spent per connection by each smtpd, I'd add that if you're not already running a local caching DNS resolver on your Postfix host, you should implement such. It could shave up to a second off the smtpd processing time for each connection, which is significant for a loaded server with 200 smtpds experiencing this problem. On 2/22/2012 12:23 PM, Alex wrote: > postscreen_blacklist_action = enforce > postscreen_dnsbl_action = enforce > postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 > b.barracudacentral.org*1 > postscreen_dnsbl_threshold = 2 > reject_rbl_client zen.spamhaus.org, reject_rbl_client psbl.surriel.com You're rejecting based on zen twice, once in Postscreen and once in smtpd. May as well remove the smtpd entry. And you may as well move psbl into postscreen. If it's going to kill a connection you may as well do it before tying up an smtpd process, which is currently a problem. You're currently doing a combined 5 dnsbl lookups per connection plus two for the forward and reverse names, for a total of 7 per connection. This may likely be part of your current problem, especially if using a high latency external resolver (ISP for instance). Four external dnsbl queries per connect may be a bit excessive for a host under this kind of load. In addition to a local caching resolver, consider using a local rbldnsd instance for serving the spamcop and psbl zones, and zen if you're a paying customer. This will cut total external dns queries down to 4 or 3 from your current 7. Along with a local resolver, this should pretty much eliminate dns latency as a factor in tying up smtpd processes. If your current average dns latency is 10ms you're looking at 0.7 seconds of time in smtpd just for dns lookups. If it's 30ms it's 2.1 seconds. That's peanuts on a lightly loaded MX, but more than significant on a host with 200 smtpds that can't seem to keep up with the load currently. -- Stan
