Erik Reuter wrote:

I used to use spamassassin a long time ago, but as you say, its resource
drain is huge. I switched to bogofilter about 1 year ago, and I have
never looked back. It is written in C and is quite fast, and it also is
extremely good at catching spam once you train it (training it is very
easy, I just have a mbox file with good emails, and an mbox file full of
spam, and I tell it which is which and then it is good to go).

If you want to reduce your spam filter computer loading, I'd highly
recommend switching to bogofilter.

We'll look at that if problems persist... but for the moment, I've just switched off auto-whitelisting in Spamassassin, which is supposed to reduce its CPU consumption considerably. The auto-whitelist file was huge -- 168 MB -- which seems like a clue that it's working hard.


... Just looked at the server settings, since we also installed
Webmin, which makes it so much easier.  We were only allowing Postfix
10 child processes, which I'm sure was waaaay too low.  It's at 50 and
I suspect it's still too low, but we'll try this for a while.


I imagine that up'ping the process max to 50 will help overall mail
performance, but would too few processes result in the weird "boom and
bust" we've been seeing? I would think that too few postfix processes
would be more likely to result in relatively long but uniform delay in
mail delivery, not "burstiness".

If mail was going to our secondary MX because no processes were available, then it could have been making it more bursty, since the secondary would try to dump all of its mail at once.


I also got rid of pop-before-SMTP because we've totally switched to IMAP. It was a CPU hog, too, even though we weren't using POP, oddly.

And the journaling file system is a hog, but I think we'll just leave it alone!

--
Nick Arnett
Phone/fax: (408) 904-7198
[EMAIL PROTECTED]

_______________________________________________
http://www.mccmedia.com/mailman/listinfo/brin-l

Reply via email to