Bill, > About every 3-5 weeks, we get hammered to the point where out gateways > are backlogging over 10,000 across 3, sometimes 4 servers. > [...] SA times are high on most e-mails.
Gary V wrote: > 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. This is generally true, although SpamAssassin 3.2.4 brings an improvement over earlier 3.2 by swifter DNS and RBL network tests handling. Shortening the 'rbl_timeout' setting in local.cf to 5 (or maybe 8) seconds (from a default 15) may help too. Douglas C. Stephens wrote: > 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. I very much agree. Moving bayes and awl to MySQL InnoDB storage engine from BerkeleyDB made a life-and-death difference at our site too. See files sql/README* in a SpamAssassin distribution package. Gary V wrote: > I think the next step would be to break down where SA spends its time. If you can afford an experimental setup, try the current SpamAssassasin 3.3 from SVN (not to forget running sa-update after an install), together with a amavisd-new-2.6.0-pre3 pre-release. At log level 2 you can see a SpamAssassin timing breakdown, e.g.: amavis[77584]: (77584-12) TIMING-SA total 2161 ms - parse: 6 (0.3%), extract_message_metadata: 28 (1.3%), get_uri_detail_list: 3 (0.1%), tests_pri_-1000: 17 (0.8%), tests_pri_-950: 0.81 (0.0%), tests_pri_-900: 1.03 (0.0%), tests_pri_-400: 27 (1.3%), check_bayes: 25 (1.2%), tests_pri_0: 1187 (54.9%), check_spf: 201 (9.3%), check_dkim_signature: 2 (0.1%), poll_dns_idle: 946 (43.7%), check_razor2: 516 (23.9%), check_dcc: 161 (7.4%), check_pyzor: 0.02 (0.0%), tests_pri_100: 1.24 (0.1%), tests_pri_500: 798 (36.9%), tests_pri_1000: 20 (0.9%), total_awl: 19 (0.9%), check_awl: 11 (0.5%), update_awl: 2 (0.1%), learn: 36 (1.7%), get_report: 1.97 (0.1%) Alternatively, running a sample message through a command line SA, e.g.: su vscan -c 'spamassassin -t -D <0.msg' and timestamping log lines may give some indication on where the problem areas within SpamAssassin are. There is also a HitFreqsRuleTiming plugin somewhere in the SpamAssassin distribution. It is a bit crude, but can produce a 'timing.log' file in a current directory at the end of a command-line session, using a sufficiently recent version of SA. Mark ------------------------------------------------------------------------- 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/
