On Tue, 12 Aug 1997, Bryan Fullerton wrote:
> >Yesterday my mail server exploded, with a load last viewable of 24:
> How fast is your connection to the 'net? If you're saturating the
> connection your system won't be able to resolve names or deliver more mail,
> so things will start clogging and snowball downhill from there. I'm
> working with a 128k connection and it's not hard to saturate, especially if
> you allow web or ftp access to the machine as well.
I too have a 128K connection. I was running mrtg to monitor my router
traffic, but it put quite a load on the machine as well! I stopped mrtg a
few weeks ago. A second 24/7 machine would be nice, for now I have one
computer dedicated to the task.
Do you have any numbers on saturating the line? For example, how many
messagess per minute would you consider saturated (average messages, say
> I'm not sure why you changed maxdomains - I've got mine set at the default
> of 20 for sending all my lists, including one with over 17,800 subscribers.
I changed maxdomains to create fewer instances of sendmail. Yes, they
would take longer to process, but they would be fewer in number.
> >I *thought* that fewer items in the queue would lower the load, even
> >though each item had more recipient addresses. Is this correct?
> Depends on a lot of things, including your personal mail philosophy.
> Personally, I prefer to send many messages with smaller numbers of
> recipients - makes for faster transmission for domains/addresses that work,
> because your sendmail doesn't have to wade thru all the 'bad' recipients to
> deliver to the good ones, it just skips to the next message. If you use
> the 'MinQueueAge' option in sendmail.cf you can reduce the time wasted on
> bad addresses even more.
>You do have to watch the max number of sendmail
> processes, though, or your machine may start refusing connections because
> there are so many processes running the queue, or just grind to a halt if
That is why I increased maxdomains, to create fewer processes.
> you have more sendmail processes allowed than your machine can handle
> (which may be what happened to you).
I think that is what happened. If maxdomains were set lower, it would have
been even worse (or so I suspect).
> If you have a large SMTP server
> upstream that you can unload some or all of your messages to that's a good
> way to go.
Unfortunately not an option.
> I've found it to be very useful, especially when used with the '-sendmail
> -odq' flags. This causes bulk_mailer to pass the -odq flag to sendmail,
> which in turn causes sendmail to queue messages instead of attempting
> immediate delivery. That way you can process the incoming messages, but
> not saturate your link by trying to deliver them all immediately. The next
> time sendmail runs the queue it'll send them all out. I use the -odq flag
> to sendmail a fair bit, actually.
Interesting idea, thanks. I'm thinking it through and see a potential
problem. Let's say I use the -odq flag, and all messages are queued.
Then,when the queue is processed there will be MANY items, and the load
will spike. Better to handle each message as it comes in, rather than all
at once when the queue is run, no?
> Works for me, anyways. :)
I really appreciate your ideas. I'm trying to tune this 486 the best I
can, then upgrade when my brains give out and the checkbook wins.