On Fri, 2004-02-27 at 08:40, [EMAIL PROTECTED] wrote: > In the past few days, it seems my main mail server has reached a critical > mass: it cannot scan incoming emails quickly enough to keep up with the > demand. As a result, the CPU shoots through the roof and making smtp > connections takes several seconds or times out altogether. I have > experimented with concurrencylocal/remote and raised the number of smtp > connections it can take, but the bottleneck is the scanning process.
concurrencyremote is just how many outgoing deliveries qmail will attempt at once; it has little to do with your load issues. concurrencylocal is how many qmail will try to deliver to local accounts. However, you said that your bottleneck is in the scanning. If that's the case, the qmail's concurrencylocal should probably not be maxed out. Just to be sure though, if you tail your mail log, you should see lines like: 2004-02-27 10:22:00.274873500 status: local 0/20 remote 0/40 If the first number is 20/20 (or whatever your concurrencylocal is set to), then your bottleneck is likely in delivery, not scanning. But I doubt this is the case; maildrop is pretty fast. > For SA, I turned off Razor, Pyzor, DCC and all RBL checks. The box is > a dual PIII-550 with 1GB RAM running FreeBSD 4.7-STABLE. performing 'spamc > -d' checks from the command line is reasonably quick. If I turn off > scanning, a ton of emails get processed and after a couple of minutes, the > cpu drops dramatically. Re-enabling scanning has the load gradually build > up again to critical mass. If the bottleneck is in the scanning, which sounds most probable, what you really want to limit is the number of incoming connections, since qmail-scanner invokes SA and virus scanners at queue-time, not at delivery-time. In your qmail-smtpd run script (mine's at /etc/qmail-smtpd/run, your location may vary), invoke tcpserver[1] with "-c number" where number is something lower than what you have right now. If you don't currently have any -c argument, I think it defaults to 40. So try backing it off to 30 and see if the load goes down. > My question(s) is/are: Are there any known issues with 1.20rc3 or anything > else above? Not that I know of. But I've only used 1.20, so don't hold me to that. > If not, would rejecting tagged spam at the SMTP level be a > better alternative? I don't think it would help, because again, your bottleneck is the scanning, not the delivery. Rejecting at SMTP time only saves delivery time. It doesn't even save bandwidth, because you have to accept the entire message and scan it before you know to reject or accept. > If so, pointers on how to implement that using SA and > qmail would be greatly appreciated. > There's an unofficial qmail-scanner patch that rejects at SMTP-time if SA score >= some configurable threshold. And there's a third-party qscanq[2] program that does virus scanning and rejects at SMTP-time if a virus is found... I'm not sure if it could be adapted to use SA. One last suggestion: perhaps you could try using spamassassin-fast instead of spamassassin-verbose in qmail-scanner? Or have you already done that? - Jon [1] http://cr.yp.to/ucspi-tcp/tcpserver.html [2] http://budney.homeunix.net:8080/users/budney/software/qscanq/ -- [EMAIL PROTECTED] Administrator, tgpsolutions http://www.tgpsolutions.com
signature.asc
Description: This is a digitally signed message part
