On 2/23/2012 1:50 PM, Alex wrote: > 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. > > It turned out increasing default_process_limit to 300 solved the > problem, although after reading your other comments, I understand > there are other areas to be improved.
Increasing the smtpd count is the quick/dirty way to fix such a problem, but doing thsi can create other problems. Which is why I had you look at other optimizations first. > I do already have a local bind resolver and will investigate rbldnsd. > I'm using munin to provide reports for bind, and it shows an average > of 60 to 80 queries per second, with peaks above 120, but doesn't show > latency. How can I report this information? I don't know that you can get this in real time, but you certainly don't need to. The important thing is that you have a local resolver. This alone guarantees you will decrease cached lookup latency to 1ms or so. Simply having a good local resolver in working order eliminates any latency issues. There is no need to measure it. > I've removed the zen and psbl queries from smtpd and moved psbl to postscreen. As Wietse confirmed, this alone will decrease the number of smtpd processes used, and it's exactly why he created postscreen. Read the docs. > How can I monitor the number of smtpd processes currently being > utilized in real-time? I don't know of any off the shelf method for this, nor any API method for querying Postfix for such info. smtpd processes will sit for max_idle seconds before terminating, waiting on additional incoming connections. So you'll always have a combination of active and idle smtpds. However, knowing which is which in real time doesn't really benefit you. There is plenty of other data available to let you know if you've got the system configured and running properly. > Even though it's set to 300, "ps ax" shows > significantly fewer than that. It would be nice to have a log of that > information over time. It's called default_process_limit. Note the last word. 300 is the peak you allowed. The default peak is 100. When everything else is tuned properly, you should be able to average 100 msgs/sec or more with the defaults. If you're seeing 60-80 dns queries/sec that would seem to indicate your connect rate is around 10-14 msgs/sec, given 6 dns lookups per connection. 10-14 connects/sec is very low connect rate. You shouldn't even need 100 smtpds for that load. Maybe my math is off here. If not, you've got more optimizing to do. Now, if every remote host connecting to you is slow, say you're in Singapore and all of your connections are in the US, it's going to take more smtpd time for each connection simply due to RTT delays, especially if satellite links are involved (unlikely today due to oceanic fiber, but possible). Now that you done some optimization, kick default_process_limit back down to 200 and see it that works. If so, keep backing it off by 25 each time until you start to see the slowdown again. Then bump it back up by 10 and leave it. Next I'd look at smtp-amavis and see if it's keeping up with demand. If it can't service requests fast enough postfix will spawn more smtpds to handle the incoming connections and then they'll sit and wait on amavis. Optimizing a complex setup as yours is a balancing act because you have so many layers depending on each other. > Thanks so much for your help, Sure thing. If you know what your peak daily connection rate is, and can share that, it would be helpful. -- Stan
