John Orthoefer wrote:
> The sendmail being forked you can't really help. Because it uses
> `sendmail -t' to send outgoing mail. But that sendmail should goaway
> after, the local deliveries have happened and the message is queued up
> for outgoing.
>
> However, sendmail will just queue the message if the load gets over a
> point. (see `O QueueLA=' in the sendmail.cf)
I don't see why the load needs to get so high as to force sendmail to
start queuing. Perhaps Majordomo should queue outgoing messages by
default, however...
> Finaly, most modern machines will run with a shared code segement so
> the sendmail and perl should both not take up that much space.
Sure, shared code, but not shared data segments. Shared code only
accounts for 300K of 10 MB processes.
> Basicly the trade off here is speed v bandwidth. It sounds like you
> are running on a machine with too little bandwidth (this is internal
> bandwidth) to do what you want, you don't care at what speed the
> e-mail gets out just that it doesn't take up too many resources. I
> suggest you get a bigger machine for your mail host. You may also
> have a problem with your whole configuration.
Actually, in my case it has nothing to do with internal bandwidth and a
lot to do with memory usage. I fail to see why a machine that just runs
sendmail and majordomo requires more than 64 MB RAM + 128 MB swap. In
my case, this event exhausted all main memory and swap before it was
barely started, and took the machine out. As soon as the machine
restarted, sendmail started to run its queue again and within moments
the load went from its normal .1-.5 to > 50 and growing every second.
The only way the tech could stop it was to blitz the mail queue.
> I see so many people who are basicly leaf nodes of the net that try
> and do all there mail processing. There should be someone upstream of
> you that is better connected that you should beable to ship your mail
> to.
Sure, there is always someone better connected. But that doesn't mean
they would be able to process the mail any better, and in particular it
doesn't solve my problem. The problem is not how to deliver the mail
once it has been queued. That's easy. The problem is getting it
queued. Irrespective of whether the local machine does the delivery or
it is handed off to another system, the same number and size of
processes get run, and it is even worse because then you have to add in
network latency to get to the mail server.
I think your advice would work well for people running Linux on
beaten-up 386's connected to badly saturated 64K links but not for
anyone with decent bandwidth and computers.
> Look at it this way. FedEx doesn't try and sort out every package at
> the local drop off. They just take it all in bulk and ship it to one
> (or is it up to two now?) site and sort it all there. The same
> should be true of e-mail. Ship it all to your ISP and let them sort
> it.
Well, I'm my ISP, and IMHO I have better equipment than the next level
up of ISP, so the FedEx analogy doesn't really work. The only
difference between me and the next level up, as far as I'm concerned, is
network bandwidth, and even then a) their machines are limited by
Ethernet capacity and b) due to point-to-point network latency their
mail servers would never even be able to push mail out at anything near
what Ethernet could handle, or even a T1.
Evan
--
Evan Champion * Director, Network Operations
mailto:evanc@synapse.net * Directeur, Exploitation du reseau
http://www.synapse.net/ * Synapse Internet
Follow-Ups:
References:
|
|
