on Tue, Sep 30, 2003 at 10:45:27AM -0700, Robin Lynn Frank ([EMAIL PROTECTED]) wrote: > -----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:
> > 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. This is more-or-less consistent with what I've seen. The fetchmail => MTA => spamassassin (specifically: spamc/spamd) combination doesn't handle large loads well. Throttling appears to manage resource starvation *and* inprove throughput. I'm not familiar with procmail itself impacting system load significantly itself, though my own recipies are fairly comprehensive (mostly concerned with filing list mail). > 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. The solution more people are reporting on various lists (debian-user, balug, svlug, linux-elitists) is exim4 with SMTP-time application of rules. This also gives a single point of control for process mangement, meaning you may turn down some traffic at SMTP connect, but sender will be aware of this. > 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. Out of curiosity: spamassassin, or spamc/spamd? The latter reduces load *markedly*. Sub-second filter times, vs. several seconds. Peace. -- Karsten M. Self <[EMAIL PROTECTED]> http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Backgrounder on the Caldera/SCO vs. IBM and Linux dispute. http://sco.iwethey.org/
signature.asc
Description: Digital signature
_____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
