Noel Jones wrote: > On 9/7/2009 1:55 PM, Mark Martinec wrote: >> Clayton, >> >>>>>>> I'm running amavisd-new 2.3.3 and it now refuses connections. It is up >>>>>>> and running according to ps but postfix cannot talk to it. The >>>>>>> postgres-db it uses is also up and running. Any ideas where to start >>>>>>> looking? >>>>>> Start with the basics... what's in the log, can you connect to the >>>>>> amavisd port with telnet, etc. >>>>> It's reachable by telnet. The only things that get logged by amavis is >>>>> when it is restarted. Postfix says connection is refused. >> Postfix keeps a memory of next-hops which appear to be down, failing >> several attempts to connect. This information is cleared after a while, >> but until it does clear, postfix can claim in the log the mailer is >> unreachable, even though it came up by now. >> >> This usually happens when amavisd is restarted while Postfix is busily >> feeding mail to it. It seems the longer amavisd restart takes and the more >> sessions are open, the higher the chances of Postfix treating the amavis >> feeds as being down. >> >> Eventually postfix would notice the service is up again, but to rush >> the recovery, a quick and ugly solution is to restart postfix, >> so that it forgets the condition. A 'postfix flush' may help too. >> >> When activity is low and a restart doesn't take long, the above drastic >> action is unnecessary. So it is best to avoid restarting amavisd during >> busy hours. So far I haven't come across a better solution - the question >> perhaps better belongs to the postfix-user mailing list. >> >> Mark >> > > Running "postfix reload" on a busy postfix system can make > things worse. All mail - both deferred and active - must be > moved to the incoming queue, then moved back to the active > queue for a fresh delivery attempt. This can cause a huge > spike in disk activity bringing the system to a near-halt > while the files are moved around. Also, any truly > undeliverable deferred mail will be retried, adding to the > load. This isn't much of an issue on a lightly loaded system, > but becomes more of a problem the more mail waiting in the queue. > > Suggested settings for tuning high-volume destinations for > fault tolerance can be found under > http://www.postfix.org/QSHAPE_README.html#backlog > > Assuming postfix 2.5 or newer, and the amavisd-new master.cf > transport is named "amavisd", setting should look something like: > # main.cf > amavisd_destination_concurrency_failed_cohort_limit = 100 > amavisd_destination_concurrency_limit = 20 > Note: the values suggested above are rather arbitrary, some > sites may need to adjust them. See postfix docs for details. > > With postfix 2.4 and earlier, you can use: > # main.cf > amavisd_initial_destination_concurrency = 2000 > amvaisd_destination_concurrency_limit = 2000 > Note: the "2000" is a rather arbitrary number, large sites may > need a higher value. See postfix docs for details. > > -- Noel Jones >
Mark/Noel Thank you both for the added information. I had not seen the xxx_destination_concurrency_failed_cohort_limit and xxx_destination_concurrency_limit related configuration options in the documentation. This may be the avenue I need to approach this from. I will see what I can find and continue my own troubleshooting on my issue. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
