On Mon, 23 Jun 2003, Simon Byrnand wrote: > At 20:54 22/06/03 -0400, Jack Gostl wrote: > > > >On Mon, 23 Jun 2003, Simon Byrnand wrote: > > > > > At 08:38 18/06/03 -0400, Jack Gostl wrote: > > > > > > >I've seen this two or three times now, and I'm not sure what to make of > > > >it. > > > > > > > >Outward appearance is that we get hit with a ton of spam, or perhaps that > > > >an RBL goes out. I wind up with many copies of spamd running, many more > > > >than the -m parameter should allow. (And forget about procmail and > > > >sendmail. Hundreds of copies.) They never seem to go away, or at best, go > > > >away very, very slowly. > > > > > > Yep, seen that before we upgraded our server recently. Basically when a > > > flood of junk comes in, your server is trying to launch more copies of > > > sendmail/procmail/spamd than it can handle, it runs out of memory, starts > > > swapping, and gets bogged down. The more it swaps, the more it falls > > behind > > > the incomming connection rate, the more processes that try to run at once, > > > so the situation compounds itself. If you're unlucky it will not > > recover by > > > itself. > > > > > > >The monitors show that disk activity is through the roof. > > > > > > Yep, and if you use vmstat you should see that it is swapping activity (si > > > and so columns) that are the primary cause of the disk activity. > > > > > > >They all but cripple the machine. Then I go in and kill sendmail, kill all > > > >the procmails and spamds, and restart things, and everything clear up very > > > >quickly. > > > > > > Of course, because when you kill all those processes you free up physical > > > memory and the machine is no longer in a state of swap thrashing, so it > > > becomes responsive again almost immediately. > > > > > > > So quickly that it makes me suspicious as to what was REALLY > > > >wrong. Maybe something more than just load, or RBL problems. Maybe a > > > >locking problem. > > > > > > Nope, this is a problem with stock installs of sendmail/procmail and/or a > > > lack of memory. How much memory does the server have ? Roughly how many > > > messages a day do you process ? > > > >We have 128mb of real memory, and we do around 4500 messages per day. > > Hmm ok, 128MB of memory is a bit marginal in my experience. Increasing that > to 256 or 512 would probably make a BIG improvement. To give you an idea we > do around 8000-12000 messages a day, and our old server was a PIII-800 with > 128MB of ram. We also do virus scanning of email. > > When I first introduced SpamAssassin I had the same problems as you - it'd > go fine for a while and then suddenly the machine would bog down to the > point where you could hardly even log in. Without SpamAssassin the machine > was easily up to the task of that volume of mail. > > Now the machine is a P4 2.4Ghz with 1GB of ram and it absolutely flies :) > Although the CPU and disk access are a lot faster too, I attribute a lot of > that to having plenty of free ram available at all times, and spare ram is > automatically put to use for disk caching... > > > > In your sendmail.cf you'll want to tune: > > > > > > QueueLA > > > RefuseLA > > > MaxDaemonChildren > > > ConnectionRateThrottle > > > >Do you have any suggested values? And what version of sendmail are you > >assuming. I don't see all those values. I have QueueLA and RefuseLA but > >not the other two. I'm at sendmail 8.10.1. > > Well I'm running 8.11.6. On the old machine with SA installed I ended up using > > QueueLA=10 > RefuseLA=20 > MaxDaemonChildren=50 > ConnectionRateThrottle=10 > > On the new server I'm now using > > QueueLA=15 > RefuseLA=25 > MaxDaemonChildren=100 > ConnectionRateThrottle=20 > > > > > of course what you tune them to depends on the specs of your server. > > > >We're running AIX. A dual processor but not a particularly fast > >server. Never had any problems until I introduced SpamAssassin. > > > > > Using the -m option of spamd IMHO is a bad idea and compounds the problem, > > > because it causes procmail and sendmail processes to *WAIT* when there is > > > too much incomming stuff to handle at once, and all these processes > > waiting > > > >I'm beginning to agree. > > With my script (snipped) on the old server I found it necessary to defer > scanning if the Load average was higher than 5, and if more than 15 local > deliveries were happening at once. Now on the new server I have the load > average threshold at 15 and 30 simultaneous deliveries. So far I've seen no > cases of bogging down.
Well... there is a new server on the way. Lots bigger and faster than this one. I just need to get through a few weeks. I'll try the sendmail throttling you suggested. -- Jack Gostl [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
