SpamAssassin (spamd) eating a lot of CPU....

[Forrest Aldrich]

(see below)

Jeremy Chadwick wrote:
> On Tue, Jan 23, 2007 at 11:02:34PM -0500, Forrest Aldrich wrote:
>   
>> Since a recent update of Spamassassin to:
>>
>> PORTVERSION=    3.1.7
>> PORTREVISION=   3
>>
>> I've noticed that each email that gets scanned causes the process to eat 
>> up 80+% of the CPU time, and it's slow...
>>
>> I'm not really sure what changed.
>>
>> Likewise, when I start it up for the first time, I see:
>>
>> [ top output ]
>> 49106 root        1 106    0   290M   267M RUN    0   0:17 *98.52%* 
>> perl5.8.8
>>
>> I have a Dell system here, and it cranks up the fan every time a message 
>> comes in now, with the recent spamd.
>>
>> Curious if anyone else has had these issues, etc.
>>
>> The system is not otherwise active, so I'm certain it's not a resource 
>> issue (or constraint thereof).
>>     
>
> I've seen this happen before, although with older SpamAssassin
> releases (though I have no proof the problem got fixed at all).
> At that time, we were using mail/spamass-rules as well.
>
> Since, we've removed using mail/spamass-rules, and haven't seen
> this problem.  Possibly there's some SpamAssassin rule which causes
> the daemon to spin when certain regexs are matched.  Not sure.
> Ours (note the much smaller memory footprint):
>
> root     58179  2.2  5.2 28088 27084  ??  S     3:58am   1:44.79 spamd child (perl5.8.8)
> root     65228  0.0  5.0 27172 26128  ??  S     5:58am   0:23.17 spamd child (perl5.8.8)
> root       313  0.0  4.3 23812 22176  ??  Ss    2Jan07  11:40.79 /usr/local/bin/spamd -c -d -r /var/run/spamd/spamd.pid (perl5.8.8)
>
> It may be worth truss'ing the perl process and opening a Bug with
> the SpamAssassin team.
>
>   

Thanks for the replies.

I did clean up the extra rules (dujor and others) and that seems to have 
resolved the problem... for now.

It's worth noting that I've had these extra rules in there for a while, 
and only recently has this caused the high CPU consumption.  So I would 
tend to wonder if there's a bug somewhere.

Might be more resource friendly if this were in C, but I don't want to 
go there ;-)


Thanks,

Forrest