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.
Regards, Simon
------------------------------------------------------- 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
