Mail processing is backing up, with a growing number of items accumulating in your upstream mail queue. Your error logs contain messages similar to:

Aug 15 14:24:19 nscan1 amavis[10479]: (10479-02) SA TIMED OUT,
backtrace: at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/BayesStore/ line 2151
eval {...} called at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/BayesStore/ line 2151
Mail::SpamAssassin::BayesStore::SQL::_put_tokens('Mail::SpamAssassin::BayesStore::SQL=HASH(0x3c9e830)', 'HASH(0x5173070)', 0, 1, 1155673350) called at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/BayesStore/
line 963
Mail::SpamAssassin::BayesStore::SQL::multi_tok_count_change('Mail::SpamAssassin::BayesStore::SQL=HASH(0x3c9e830)', 0, 1, 'HASH(0x5173070)', 1155673350) called at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/ line 806
80)', 0, 'Mail::SpamAssassin::Message=HASH(0x4f046a0)',
'HASH(0x5176870)', 'undef') called at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/

Possible Causes

  1. Your system may be unusually busy or heavily loaded for brief periods of time, during which some SpamAssassin processes take too long to complete. As long as this is just an occasional thing, there's nothing to worry about, since no mail is lost when this happens--it remains in the upstream queue to be retried, so mail that failed the first time may succeed during a retry if the system load has dropped in the meantime.
  1. You may have SpamAssassin's auto-expiry mechanism enabled, in which case SpamAssassin may be deciding to do an opportunistic Bayes token expiry at a time when your traffic levels are too high to handle the extra load.
  1. You may be using the generic SQL engine for SpamAssassin, rather than one that's been optimized for MySQL or PostgreSQL. The generic engine is considerably less efficient.


  1. Tell amavisd-maia to wait a bit longer for SpamAssassin before giving up. In your amavisd.conf file, set the following to increase the timeout value to 60 seconds, for example:
$sa_timeout = 60;
  1. Disable SpamAssassin's auto-expiry mechanism, and schedule a cron job to do an expiry run once a day at off-peak hours. See the auto-expiry page for more details about how to do this.
  1. Switch to the use of a database-specific engine instead of the generic SQL engine, if you can. Users of MySQL 4.1 and later should use:
bayes_store_module   Mail::SpamAssassin::BayesStore::MySQL

whereas PostgreSQL users should use:

bayes_store_module   Mail::SpamAssassin::BayesStore::PgSQL

Back to FAQ

Last modified 16 years ago Last modified on Aug 17, 2006, 5:20:55 AM