You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Paul Crittenden <cr...@simpson.edu> on 2004/11/16 15:37:16 UTC
Tuning SpamAssassin
I'm running SpamAssassin 3.0.1 on a Compaq Alpha running Tru64-Unix,
sendmail 8.12.10. are there any guidelines to figuring out how many
children you need when running spamc/spamd. I know that having to many is
as bad as having to few. I have tried 10, 25 and 30. Thing seem to be going
better as I continue to increase the number of children but how do I know
when I have gone to high and need to decrease the number?
Also, with single emails they seem to go through fairly quickly but we have
several lists. These seem to take forever to go through. What can I do to
improve this?
Thanks in advance the help.
Paul Crittenden
Computer System Manager
Simpson College
email: crittend@simpson.edu
Phone: (515)961-1680
"You don't have to attend every argument you're invited to."
Re: Tuning SpamAssassin
Posted by Matt Kettler <mk...@comcast.net>.
At 08:37 AM 11/16/2004 -0600, Paul Crittenden wrote:
>I'm running SpamAssassin 3.0.1 on a Compaq Alpha running Tru64-Unix,
>sendmail 8.12.10. are there any guidelines to figuring out how many
>children you need when running spamc/spamd. I know that having to many is
>as bad as having to few. I have tried 10, 25 and 30. Thing seem to be
>going better as I continue to increase the number of children but how do I
>know when I have gone to high and need to decrease the number?
Check your swapfile stats. (use top or tool of your choice) If you're
digging into the swap to any significant degree, you've gone too far.
Note: many OS's will page out stuff that's not been used in a long time.
Compare swap usage with your "available" ram that can be used if programs
need it (free physical ram+buffer ram). There should be more available ram
than swap used.
Basicaly you can keep running more spamd's as long as you're not running
out of ram. Once you run out of ram, it starts swapping, and things quickly
grind to a halt. Leave some extra megs free, at least 40mb if you include
buffers, that way bumps in memory load won't slow you down.