Bill, I agree with MrC that looking at the performance diagnostic tips at http://www.ijs.si/software/amavisd/README.performance.txt is a good thing. Also, have you turned on this option in /etc/amavisd.conf?
$enable_db = 1; # enable use of BerkeleyDB/libdb (SNMP and nanny) Looking at the output from amavisd-agent (from the source tarball) was quite helpful for confirming that it was SpamAssassin that was contributing to my per-message processing times. However, if your ClamAV check times are also high, have you confirmed that Amavisd is calling ClamAV via a clamd socket instead of spawning a clamscan each time? Are you using Bayes or AutoWhitelist SA checks? If so, are you using SA 3.2+ with SQL storage for Bayes and/or AutoWhitelist? As I wrote to this list on Feb 6, 2008, (see "How many emails does amavis scan at once?"), using MySQL storage reduced my SA per-message check time by an order of magnitude by all but eliminating the write-lock contention caused by my previous default use of Berkeley Sleepycat db files. I needed to use strace on the Amavisd child processes to discover this was happening. FYI, you'll need SA 3.1 or higher to go to SQL storage for Bayes and AutoWhitelist. As for DNS, I use caching-only a DNS daemon on my MTA+Amavisd boxes, not only for load reduction on my core DNS servers, but also for higher availability. Are you using DNS- based checks in SpamAssassin? My system gets a lot of spam from unregistered SMTP client IPs and non-existent sender domains, so I've found having the MTA drop these during the initial SMTP transaction is much more efficient than rejecting them post-queue in Amavisd. At 12:09 PM 2/12/2008, Clifton Royston wrote: >On Tue, Feb 12, 2008 at 10:51:25AM -0700, Gary V wrote: >> Bill Wrote: >> >> > > 5. Although some of the processes are older, we have had this issue >> > > regardless of versions (we will be upgrading in the next few days, >> > > Amavisd, PF, SA, and ClamAV). >> >> Just so you are aware, in my experience each new major version of SA >> has historically been more resource intensive than the last. If you >> are already having problems getting stuff processed, upgrading SA may >> _possibly_ make matters worse. > > Good point. > > If you want to solve this problem, you should re-enable at least some >basic logs from all the services involved, now that you've ruled >logging out as the main problem source. Without logs, trying to solve >your problem will be like throwing darts in the dark. > > If you suspect DNS lookups of being a major component, I'd recommend >adding DJB's dnscache on every server, configured to forward to a shared >cache server (Bind or dnscache.) dnscache is less resource intensive >than Bind and should reduce your lookup times. -- Douglas C. Stephens | Network/DNS/Unix/Windows Admin System Support Specialist | Email Postmaster Information Systems | Phone: (515) 294-6102 Ames Laboratory, US DOE | Email: [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
