On Fri, Feb 02, 2007 at 04:16:25AM +0000, Wookey wrote: > The log for the bad and good runs are attached. The bad run stopped at > this line: > [11544] dbg: bayes: expiry max exponent: 9 > for several minutes before continuing from > [11544] dbg: bayes: atime token reduction
I'm seeing exactly the same thing. I can eliminate NFS; that's not involved in my setup. strace and lsof show that the spamd child is very slowly pread64()ing ~/.spamassassin/bayes_toks. I think the problem is simply that Bayes auto-expiry is enabled and is taking way too long. I've turned off bayes_auto_expire here and will set up 'sa-learn --force-expire' or similar to run from cron to see if that helps; it seems to be helping so far. I'm not very impressed with the default configuration, though; it's let through a hundred or so spam messages just today due to spamd timing out while doing token expiry. Manual expiry is a hassle and I'd rather it weren't necessary. Is it possible for only one spamd child to do the expiry while the others proceed as normal (perhaps without learning)? If so, perhaps the parent could avoid distributing work to a child that's busy doing expiry, and could somehow tell spamc to wait longer until that child finishes? (I'll also try converting to SDBM_File and see if that helps; I'm still on the default DB_File.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
