On 9/15/2009 1:40 PM, Clayton Keller wrote: > Noel Jones wrote: >> On 9/15/2009 11:21 AM, Clayton Keller wrote: >>> Clayton Keller wrote: >>>> 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. >>>> >>> Noel, >>> >>> I'm not seeing those options in the 2.3.x versions. Could I be >>> overlooking them. >>> >> >> Yes, this will work on postfix 2.3 using the "2.4 and earlier" >> settings mentioned above. The settings won't show up in >> "postconf" output. >> >> See postfix docs or there are several threads about this in >> the postfix-users archive. >> >> -- Noel Jones >> > > Thanks. I apparently chose not to read over the "and earlier" my apologies. >
I just wanted to follow-up on this thread and mention that although I did make the changes to postfix (amavisd_initial_destination_concurrency, and amavisd_destination_concurrency_limit) as suggested by Noel my issue was still occurring. However, I realized rather than a true reload of the amavisd-new, I was issuing a condrestart of the service itself and in some cases a restart command as well. With some additional modifications on my end and using an "amavisd reload" command the deferred connection issue I was seeing is no longer present. Clay ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ 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/
