CPU usage very high (spamd) (was Re: relocating tmp files?)

[email builder <em...@yahoo.com>]

Thanks so much.  Unfortunately, I don't see much change in my CPU usage by spamd.  I am
at a loss, as I've spent almost an entire day reading old mailing list threads and the
wiki, but no one has seemed to post anything concrete as to why spamd would eat so much
CPU (in my case, it spikes to as much as 35%, so running 5 max children really taxes my
machine (2.8GHtz!).  I run a local DNS server and as I am running Fedora, I set the
language when I start spamd:

LANG=en_US; export LANG; TMPDIR=/tmp/spamassassin; export TMPDIR
spamd -d -q -x --max-children=5 -H /etc/razor -u maildrop -r /var/run/spamd/spamd.pid

With a ramdisk now for DCC temp files, I am at an absolute loss as to what else I can
change to get spamd to cooperate.  Anyone have any advice??  TIA!


> 64MB should be plenty -- those files shouldn't stick around once
> a scan has completed, and they should all be 250KB or less in
> size.
> 
> In my experience tmpfs helps quite a lot, but in this case it's
> a trivial amount of the overall total runtime.
>
> > > > I have been under the apparently false presumption that spamd prcessed
> > > > its messages in memory (perhaps this explains why each spamd process can
> > > > oft take up to 25% cpu?).  I recently looked in /tmp and found lots of
> > > > left over spamassassin.xxxx.xxxxxx.tmp files (the first four x's are
> > > > numeric, the second set of x's are alpha-numeric).
> > > > 
> > > > I am interested in placing those files in a tmpfs, but do not want to
> > > > put my whole /tmp directory under tmpfs.... but I can't for the life of
> > > > me find any configuration settings that tell spamd where to place its
> > > > temp files.  Do I need to change something in the code itself?
> > > 
> > > nope -- setting the std env var TMPDIR  will do it.  those files are
> > > created if you're using Pyzor or DCC.
> > 
> > Thank you kindly!  
> > 
> > Might I ask if anyone else has gone with any type of ramdisk for this directory and
> if so
> > if it helped in any way (just five minutes running it so far; I don't see any
> significant
> > performance gain)?  I am wondering how to size it as well.  I have started out with a
> > 64MB tmpfs, but not sure if I'll need more.  I am tempted to size it similar to the
> > following recommendation from a how-to for creating a ramdisk for amavis:
> > 
> > n * (1 + max(expansionfactor)) * $message_size_limit
> > 
> > Thoughts anyone?  What else could be eating up so much CPU??
> > 
> > > > Pointers to anything I missed or other help greatly appreciated!  I am
> > > > running 3.0rc5 (as I understand it, only documentation changes were made
> > > > between rc5 and the official release), Fedora core 2, 2.8GHtz
> > > > hyperthreaded Pentium IV, 1 GB RAM, spamc out of Courier Maildrop to
> > > > spamd.  Spamd pounds my system all day long (cpu but not memory).  I run
> > > > max-children beween 5 and 8 (and all user prefs in (My)SQL, as well as
> > > > AWL and Bayes, although I cannot run bayes/awl without mail backing up,
> > > > as it appears to be too slow).


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: CPU usage very high (spamd) (was Re: relocating tmp files?)

[email builder <em...@yahoo.com>]

Hooray!  Just when I was thinking about how to start another thread asking the same
question...  I am pleased that this thread can continue.  :)

Read below...

> > Thanks so much.  Unfortunately, I don't see much change in my CPU usage by
> spamd.  I am
> > at a loss, as I've spent almost an entire day reading old mailing list
> threads and the
> > wiki, but no one has seemed to post anything concrete as to why spamd
> would eat so much
> > CPU (in my case, it spikes to as much as 35%, so running 5 max children
> really taxes my
> 
> I think there are several theories on SA processor usage.
> 
> 1.    bayes expire

I have not been using Bayes due to what appears to be such a resource problem with SA
that if I add the time on top of that for Bayes, my mail server will start backing up
email.  I would *like* to figure out what is consuming so much for spamd so I can
possibly turn Bayes on again.

> 2.    bayes expire jorrnal bug

Is this bug fixed in development versions of the software?

> 3.    Some rule with something like an .* in it that is looping like mad on
> certain text patterns.

I only use stock rules, is this a possibility with what I get with the standard SA
download?

> 4.    Something else.

:)

> If you are getting suddenly huge bayes journals along with your processor
> usage, it is #2.

I use SQL-based Bayes, but again, I have autolearn temporarily turned off.

> If SA is taking 2-5 minutes randomly, and repeating on the same mail message
> doesn't have the same result, it may be #1.

Times are not out of the ordinary I think (at the busiest of times, they range from
almost as low as one second to typically 1 minute at the highest).  The problem merely
appears to be that spamd eats up so much of the CPU that I can do little else for fear
that the box will collapse into flames.

> If SA is taking a long time to process a specific message every time, it is
> probably #3.

I don't *think* this is a problem, but haven't been watching specific messages.  Is this
problem a possibility on a 100% stock ruleset?
 
> The first thing is to try to determine whether you are seeing spikes or
> constant heavy load.  I think you are implying that you see spikes.

Sorry, I am saying that I see a consistently high load (spamd bounces around between 5%
and 40% CPU... I only meant to use the word spike to say that spamd children usually
average 20%/30% but that almost 50% is only a bit unusual).  Again, the problem seems to
be a fairly consistent high CPU usage by spamd.  A sample from top:

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1401 maildrop  16   0 39744  34m 6840 R 28.3  3.4   3:04.18 spamd
 
And this is how I start spamd:

LANG=en_US; export LANG; TMPDIR=/tmp/spamassassin; export TMPDIR
spamd -d -q -x --max-children=5 -H /etc/razor -u maildrop -r /var/run/spamd/spamd.pid

/tmp/spamassassin is mounted with tmpfs

we also run named on the same machine

if it's important, this is 3.0rc5, downloaded and compiled manually (not a CPAN install)

also, this is a Fedora Core 2 machine (2.8P-IV hyperthreaded, 1GB RAM)

spamc is called from maildrop as such:

if ( $SIZE < 262144 )
{
   exception {
      xfilter "/usr/bin/spamc -u $LOGNAME"
   }
}


Any advice or even just pointers on any more reading I can do would be highly
appreciated!
 
TIA!

> The next thing to do is to try to figure out of the spikes correlate with
> certain messages, with certian times, or occur randomly.  You can also check
> for the bayes journal bug fairly easily.
> 
> If you end up with a particular message that eats the processor alive, you
> probably also have a bad rule that is the real culprit.  DProf I believe it
> is should perhaps be able to track the problem down to the rule if you have
> an example message.
> 
>         Loren



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Re: CPU usage very high (spamd) (was Re: relocating tmp files?)

[Loren Wilton <lw...@earthlink.net>]

> Thanks so much.  Unfortunately, I don't see much change in my CPU usage by
spamd.  I am
> at a loss, as I've spent almost an entire day reading old mailing list
threads and the
> wiki, but no one has seemed to post anything concrete as to why spamd
would eat so much
> CPU (in my case, it spikes to as much as 35%, so running 5 max children
really taxes my

I think there are several theories on SA processor usage.

1.    bayes expire
2.    bayes expire jorrnal bug
3.    Some rule with something like an .* in it that is looping like mad on
certain text patterns.
4.    Something else.

If you are getting suddenly huge bayes journals along with your processor
usage, it is #2.
If SA is taking 2-5 minutes randomly, and repeating on the same mail message
doesn't have the same result, it may be #1.
If SA is taking a long time to process a specific message every time, it is
probably #3.

The first thing is to try to determine whether you are seeing spikes or
constant heavy load.  I think you are implying that you see spikes.

The next thing to do is to try to figure out of the spikes correlate with
certain messages, with certian times, or occur randomly.  You can also check
for the bayes journal bug fairly easily.

If you end up with a particular message that eats the processor alive, you
probably also have a bad rule that is the real culprit.  DProf I believe it
is should perhaps be able to track the problem down to the rule if you have
an example message.

        Loren