Spamassassin speed

[Robert Swan <rs...@nskinc.com>]

I am running the new spamassassin 3.10 and it seems a bit slower that
the previous version 3.06. Although it IS doing a better job at
identifying SPAM it takes an e-mail longer to be processed that before
or there are not as many processes. My first thought is that the
previous version used more spamd processes (6) and now there are only 3
is there anyway to increase the number of processes I know the hardware
we are running on can handle more...I am running Redhat9 and spamc/spamd
with postfix..

 

Anyone?

 

 

 

Thanks,

Robert

 

 

 

 

 

 

Peace he would say instead of goodbye....peace my brother.

 

Re: Spamassassin speed

[Matt Kettler <mk...@comcast.net>]

At 04:03 PM 12/5/2005, Robert Swan wrote:
>I am running the new spamassassin 3.10 and it seems a bit slower that the 
>previous version 3.06. Although it IS doing a better job at identifying 
>SPAM it takes an e-mail longer to be processed that before or there are 
>not as many processes. My first thought is that the previous version used 
>more spamd processes (6) and now there are only 3 is there anyway to 
>increase the number of processes I know the hardware we are running on can 
>handle more…I am running Redhat9 and spamc/spamd with postfix..


man spamd

You'll need to edit your init script or sysconfig to tweak the number of 
children. (On redhat boxes the script usually lives in /etc/rc.d/init.d. 
The RPM might have added a spamd to /etc/sysconfig, and if it did, editing 
that would be preferable.)

However, it sounds like you'll not get any benefit from that. The default 
settings for 3.1.0 allow spamd to spawn up to 5 children if load demands. 
They also dictate it should try to keep 1 spare ready, and if there's more 
than 2 spares doing nothing, to kill of spamd instances until only 2 idle 
children exist.

Since your running value is 3, it sounds like only one or two spamd 
children is ever needed. Otherwise the min-spare would cause it to inflate 
closer to 5.

As an experiment, you can also try using the 3.0.x forking algorithm by 
passing the --round-robin parameter to it. This will give you the classic 
"5 children used in a round-robin fashion" behavior. Theoreticaly this 
should be slower, not faster, due to less memory being available for 
caching from the extra un-needed children, and the constant switching of 
children forcing the processors L1 and L2 cache to re-populate.