-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 30 September 2003 04:43 am, Karsten M. Self wrote: > on Sun, Sep 28, 2003 at 05:48:36PM -0700, Robin Lynn Frank ([EMAIL PROTECTED]) wrote: > > From 9/18 till 9/24 we were being hammered with a huge spike in > > traffic that our server handles for 6 domains. In order to allow a > > per user config, we used postfix, forward files, procmail, > > spamassassin and tmda. > > > > Postfix handled the load with no problem. TMDA kept chugging along. > > Procmail and spamassassin didn't fare as well. From what I can > > determine, postfix delivered to procmail where things , ah, err, got > > constipated. That is until spamassassin pooped on its own lock file > > and procmail's pipe burst. Surprise, there were a boatload of emails, > > some as old as five days. In the 20 minutes it took me to get back to > > the office, we bounced that boatload of messages. > > What were the specific characteristics of the choke-up? I've had to > have the box filtering my mail killed (hard boot, no shutdown) twice > over the past summer due to spamassassin filtering load, during the > SoBig traffic spike. We've weathered Swen fine. > > System here was running exim 3, spamassassin, and local filtering for > some accounts via procmail. Three accounts are also served by fetchmail > from remote POP3 servers, with mail loads as high as 300-600+ messages, > though fetches are generally capped at 20-40 per pull, polling ever 3-4 > minutes. I also pulled my own fetchmail polling out of the systemwide > configuration, and feed the output directly into procmail. > > At one point system load climbed above 120, on this 160 MHz PA-RISC box. > > There are several tuning options to set: > > - Spamassassin has a max-children parameter. Use this. Once you've > got a few child processes running, you're probably saturating CPU > and/or bandwidth. We set this at 10. > > - Similarly, exim (or your MTA) will have a concurrency limit. Set > this as well. We've since upgraded to exim4, but IIRC the level was > 10. > > - Depending on your OS/distro configuration, it's possible to set > per-user limits through ulimit or /etc/security/limits.conf. We > capped 'mail' at 30 (10 exims, 10 SAs, and some slack). > > At this point the system was running reliabily without going into high > load, even under very high mail traffic. > > Pre-filtering mail with executable attachments and rejecting these at > SMTP connect will also greatly reduce system load. > > > Another setting you're goin to want to look at are your system max files > and max processes values. GNU/Linux is notable for setting these lower, > and handling resource starvation worse than, FreeBSD. 2.4 kernels > increase these limits and allow for compiled-in and/or dynamic > configuration of these values. > > > Useful information for those using TMDA in conjunction with other tools. > > > Peace.
The primary problem appears to have been procmail/spamassassin. The first clue was that our users started seeing groups of 5 to 10 pieces of email several days old in their MUAs. Since this occurred at the height of swen, they wrongly attributed it to other servers being bogged down. Since they were still seeing "current" mail arriving, they were further lulled into a false sense that all was well. Since procmail was accepting what postfix was handing it, the mail logs provided no obvious alarm. The crunch came when a number of security scripts began running, increasing system load, and fetchmail retrieved an unusually large amount of mail from several remote servers we use. At that point spamassassin and procmail failed and postfix "determined" the mail was undeliverable. If it weren't for the fact that we routinely receive a number of large reports by email, we would have set a size limit on mail to block swen efficiently, but we do block all MS executables. If I get a free moment, I may unzip the logs from that time period and examine them further. In the future, I may consider using spamassassin in a limited capacity, but procmail is out of the equation. - -- Robin Lynn Frank | Director of Operations | Paradigm-Omega, LLC Email acceptance policy: http://paradigm-omega.com/email_policy.html Our current s$p%a&m-t*r#a^p: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ecFBzXwq4t8X1KoRAhfIAJ9b4kDRJUsC29zJ2A9lZ3pPHvSPBQCgwK4t Jfmt2eoyXabZVfa8S4bjb9A= =g3mb -----END PGP SIGNATURE----- _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
