You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ross Kramer <rk...@mailwise.com> on 2004/05/10 15:44:20 UTC
Spamassassin performance...
I'm currently running Spamassassin 2.55 on an enterprise level with
roughly 3 to 4 thousand rules on top of SA's default ruleset. I'm not
using Bayesian or Pyzor or Razor or anything, just straight SA rules.
So here's my question:
My system is passing close to 6 messages per second. Needless to say,
I've been hitting a glass ceiling in terms of performance. My normal
system loadavg ranges between 15 and 30, and most of it is spamd. I'm
running redhat 8.0 on a 2.4 Ghz Xeon with a gig of RAM. What can I do to
squeeze more performance out of spamd? I've tried upgrading to SA 2.63,
but it complains about the 2.55 rules. I've also tried using SA with a
milter (spamass-milter), but it didn't seem to make to much of a
difference from the normal shell script I currently use.
I have to get the loadavg down and have this system capable of passing
more mail... What does one do when one has to run Spamassassin with such
a large thru-put?
Thanx!
R Kramer
Re: Spamassassin performance...
Posted by Lucas Albers <ad...@cs.montana.edu>.
Try running mimedefang instead of spamd.
I also run mimedefang, and it should easily scale up to 300k messages with
your hardware. The tmpfs volume on mimedefang appears to speed things up.
Procmail does not scale.
Sylvain Robitaille said:
> On Mon, 10 May 2004, Ross Kramer wrote:
>
>> I'm running redhat 8.0 on a 2.4 Ghz Xeon with a gig of RAM. What can
>> I do to squeeze more performance out of spamd?
>
> Is the system swapping at all? Look at the "so" column in the output of
> vmstat (get it to produce at least a few timed lines of output,
> otherwise what you're looking it will be an overall reading since the
> time the system was last booted). If you see regular swap activity,
> you'll definitely gain performance from adding memory: Your processes
> will complete much sooner, and this will in turn reduce the load average
> on the system, which will result in more CPU time available for those
> same processes.
>
> My own mail servers here are dual 2.4 Ghz Xeons, with 4-8GB of RAM
> (depending on wether we're talking about a primary or secondary mail
> exchanger), running Slackware-9.1 with kernel upgrades and locally
> installed Sendmail-8.12.10, MimeDefang-2.35, and SpamAssassin-2.60 for
> mail processing.
--
Luke Computer Science System Administrator
Security Administrator,College of Engineering
Montana State University-Bozeman,Montana
Re: Spamassassin performance...
Posted by Sylvain Robitaille <sy...@alcor.concordia.ca>.
On Mon, 10 May 2004, Ross Kramer wrote:
> I'm running redhat 8.0 on a 2.4 Ghz Xeon with a gig of RAM. What can
> I do to squeeze more performance out of spamd?
Is the system swapping at all? Look at the "so" column in the output of
vmstat (get it to produce at least a few timed lines of output,
otherwise what you're looking it will be an overall reading since the
time the system was last booted). If you see regular swap activity,
you'll definitely gain performance from adding memory: Your processes
will complete much sooner, and this will in turn reduce the load average
on the system, which will result in more CPU time available for those
same processes.
My own mail servers here are dual 2.4 Ghz Xeons, with 4-8GB of RAM
(depending on wether we're talking about a primary or secondary mail
exchanger), running Slackware-9.1 with kernel upgrades and locally
installed Sendmail-8.12.10, MimeDefang-2.35, and SpamAssassin-2.60 for
mail processing.
I haven't counted the number of additional rules that I'm using beyond
SpamAssassin's default set, but I'd be surprised if I have as many as
you report having. I'm seeing (physical) memory usage as high as 2.5 GB
quite regularly, and very infrequent (though non-zero) swapping
activity.
I recommend you measure your memory and swap usage, and if you're
swapping at any rate that seems remotely "regular", you'll very likely
benefit from some additional physical memory.
I hope that helps.
--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca
Systems analyst / Postmaster Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------