Hi Peter:


I was thinking of that also. But didn't you lose the benefit of 'checkuser' patch. We have one domain that used to have a catch-all and now gets 40,000 spams a day addressed to every possible name. We shut down the catch-all and the checkuser patch rejects them all saving us all kind of CPU cycles.

At 03:29 PM 2/27/2004, you wrote:
Jeff,
We had a similar problem, and our bottleneck was SpamAssassin and Clam Scanner. We ended up putting SpamAssassin and Clamd on a seperate machine that simply scanned the incoming messages and passed them onto the primary mail machine that housed the vpopmail accounts, etc.


All you need to do is install Bill's toaster on a second machine with Qmailscanner, SpamAssassin, etc, etc. and then setup that machine to forward all mail to your primary box in /var/qmail/control/smtproutes

Works like a charm, just make sure DNS points to the scanning server in the MX route.

Peter



Jeff Koch wrote:


Hi Bill:


Thanks for the reply.

I know how to run mysql from another server but how would one move spamd and clamd to another server? Your other suggestions are good but we're using a 1U rack server that unfortunately has room for one drive (big mistake!).

At 02:44 PM 2/27/2004, you wrote:

Jeff Koch wrote:

Does anybody have any suggestion for improving the performance of a mailserver runnning qmail/vpopmail/qmailadmin/qmail-scanner/spamassassin? We're using a 2.4Ghz P4 with 1GB RAM and a 40GB SCSI drive. The operating system is a basic RH8.0 install with the ext3 journalling file system. We're handling about 50K messages/day and seem to exhausting the capabilities of the server. During peak periods CPU idle time reaches 0% and load averages will exceed 10.0
We've seen some recommendations ( http://people.redhat.com/alikins/system_tuning.html , for example) for changing hard disk and file system parameters mostly having to do with read/write caching and cache sizes and minumum delays before writing to disk but we have been afraid to try any of these for fear of making things worse.
We would welcome any suggestions or URL's that you could point to - particularly with respect to performance tuning that will work with qmail.
Thanks


Jeff,

In my experience, the first bottleneck is usually disk i/o. Some steps you can take to alleviate this are:

1. Put /var/qmail/queue on its own disk, preferably not a raid.
2. If you use qmail-scanner, put /var/spool/qmailscan on its own disk
3. You can also try putting /var/log/qmail on its own disk if you can. But at least try and keep it on a different disk than /var/qmail/queue


Next, qmail-scanner/clamd/spamd tend to be the bottleneck. You can try qscanq/qmail-spamc to get rid of qmail-scanner's perl overhead.
I have had success with qscanq on Linux, but had unexplained qq read errors on FreeBSD that I have not been able to explain yet. So I'd try this only with caution. You also might try moving some components off of this machine, like clamd, spamd, or even MySQL if you use it.


Hope this helps,

Bill Shupp


Best Regards,

Jeff Koch


Best Regards,


Jeff Koch, Intersessions


Reply via email to