Date: Wed, 24 Jan 2007 10:24:07 -0500 From: Forrest Aldrich <forrie@forrie.com> To: ports@freebsd.org Subject: Re: SpamAssassin (spamd) eating a lot of CPU.... Message-ID: <45B77A17.70800@forrie.com> In-Reply-To: <20070124151552.GA8825@icarus.home.lan> References: <45B6DA5A.9080704@forrie.com> <20070124151552.GA8825@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
(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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45B77A17.70800>