Howdy all. I'm running version 3.0.0 on Gentoo Linux (using the 3.0.0-r1 ebuild). The machine is a dual P3/450 and it is also running sendmail 8.12.11 and it handles mail for 20 or so domains with less than 20 users total. So, the mail volume is pretty low.
I'm running spamd in the following manner: /usr/sbin/spamd -d -r /var/run/spamd/spamd.pid -u mail -x -m 10 -L I'm running spamc out of my /etc/procmailrc (with no options). What I've noticed is that after spamd has been running for a little while, it starts to take longer and longer to check each message. Here is a snippet of my times from 2.64: clean message (-104.9/5.0) for user1:8 in 0.8 seconds, 1129 bytes. clean message (-104.9/5.0) for user2:8 in 0.9 seconds, 1231 bytes. clean message (-104.9/5.0) for user1:8 in 0.8 seconds, 1231 bytes. clean message (-4.9/5.0) for user1:8 in 1.1 seconds, 1046 bytes. When I first start spamd, I see times that are very close to this. But, within 10-20 minutes, they start to climb. Here is how they look right now (I started spamd 40 minutes ago). clean message (-102.8/5.0) for user1:8 in 5.8 seconds, 1282 bytes. clean message (-5.0/5.0) for user2:8 in 41.8 seconds, 2867 bytes. clean message (-100.0/5.0) for user3:8 in 37.8 seconds, 2250 bytes. If I let spamd run for several hours, I'll see times near 200 seconds per message and it seems to keep increasing. I have always had "skip_rbl_checks 1" in my local.cf. But, I've been trying to isolate what's caused this new slowness, so I've also tried to first disable razor2, dcc and pyzor and that didn't seem to make much difference. Then I set use_bayes to 0 and that seems to help a little bit, but I still see long delays. The delayed times that I show above are for this configuration: # Enable the Bayes system use_bayes 0 # Enable or disable network checks skip_rbl_checks 1 use_razor2 1 use_dcc 1 use_pyzor 1 I also tried "lock_method flock" and I didn't see much success their either. Anyway, I was hoping someone else had seen this behavior and or maybe someone could shed some light on what might be the cause of this? Thanks, Shane -- Shane Hickey <[EMAIL PROTECTED]>: Network/System Consultant GPG KeyID: 777CBF3F Key fingerprint: 254F B2AC 9939 C715 278C DA95 4109 9F69 777C BF3F Listening to: The Courtship of Birdy Numnum - The Parapalegic-Homoerotic Episode
