Two things that I can think of:I'm using qmail 1.03, SpamAssassin 2.55, Perl v5.8.0, and procmail v3.22 to run a STMP gateway server to filter spam. This system is a dedicated SMTP/SpamAssassin server and does nothing else. I'm not sure if SA is overloading the system because of the high volume of mail, or if it's mis-configured. Any comments or suggestions as to how to improve performance or if anyone notices any glaring mistake in my setup (.procmailrc) - I would be most grateful.
I've poked around google and the SA FAQ and haven't turned up much other than possibly running SA on another server - but that's not really an option for me. The system is a 1GHz Dell w/ 256MB of RAM (and 494MB of swap, and normally top shows the swap at 2% in use) running FreeBSD. 'top' reveals around 20% total CPU load.
I'm running spamd:
/usr/local/bin/spamd -a -c -d -r /var/run/spamd.pid
All users are setup to run their mail through spamc (see below). There are aprox 55 email addresses handled by this server. The problem is the server seems to get way behind on processing messages in the mail queue and the CPU also gets bogged down.
The following messages show up in syslog: 15:51:02 /kernel: swap_pager_getswapspace: failed 15:51:56 last message repeated 3 times 16:02:17 /kernel: swap_pager_getswapspace: failed 16:02:19 last message repeated 11 times 16:05:07 last message repeated 6 times 16:05:14 /kernel: swap_pager_getswapspace: failed 16:05:32 su: mngr to root on /dev/ttyp0 16:05:33 /kernel: swap_pager_getswapspace: failed 16:06:03 last message repeated 10 times
There's also a ton of these 'out of swap space" messages in syslog as well:
15:16:43 /kernel: swap_pager: out of swap space 15:17:03 /kernel: pid 60524 (perl), uid 1010, was killed: out of swap space 15:40:35 /kernel: pid 62180 (perl), uid 1001, was killed: out of swap space 16:05:33 /kernel: swap_pager_getswapspace: failed 16:06:03 last message repeated 10 times 16:14:43 /kernel: pid 69291 (procmail), uid 0: exited on signal 11
A 'ps auxww | grep spamd', reveals several (like 4 or 5) of spamd processes running in parallel (owned by the user who spamd is processing mail for). Some seem to get stuck and run indefinitely until they are killed because they ate up all the swap space on the system.
A basic users configuration on my system is as follows:
The .qmail file in the home directory launches procmail: | preline procmail
The .procmailrc file checks for spam. If it scores a 5 or greater, I forward it to a mailbox that collects spam, otherwise forward it to my personal exchange server account:
# SpamAssassin ~$HOME/.procmailrc EXCHANGE_SERV = [EMAIL PROTECTED] SPAMBOXDATA = "[EMAIL PROTECTED]"
:0fw: /var/tmp/spamassassin.lock * < 256000 | spamc
# Mails with a score of 15 or higher are almost certainly spam (with 0.05% # false positives according to rules/STATISTICS.txt). Let's put them in a # different mbox. (This one is optional.) :0: * ^X-Spam-Level: \*\*\*\*\* ! $SPAMBOXDATA
:0 ! $ EXCHANGE_SERV
Here are the overall stats on the qmail system over the past 16 hours or so.
Completed messages: 4578 Recipients for completed messages: 5037 Total delivery attempts for completed messages: 5079 Average delivery attempts per completed message: 1.10944 Bytes in completed messages: 46039454 Bytes weighted by success: 43072620 Average message qtime (s): 492.89
Total delivery attempts: 7101 success: 3981 failure: 1061 deferral: 2059 Total ddelay (s): 2133766.488631 Average ddelay per success (s): 535.987563 Total xdelay (s): 325547.260610 Average xdelay per delivery attempt (s): 45.845270 Time span (days): 0.685022 Average concurrency: 5.50042
1) If you are doing any RBL checking, try turning it off. There was some discussion earlier about processes with long time outs when trying to do RBL checking and not getting through. Check the archive for details. There may also be some DNS issues that you aren't aware of.
2) check your softlimit settings in your qmail run files and make sure they are reasonable, not too big, not too small.
Free advice:
I have found that if you are going to run qmail, http://www.lifewithqmail.org is a valuable book to have around. It has a really good troubleshooting section.
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
