We are running MD 1.93 on Linux on a Pentium 90 with 48 M of RAM. We do dump
all mail to a larger outbound mailer for delivery.
I did a 51,850-address mailing, and this what happened:
Message rec'd by listserv.prodigy.com:
03:49
MD started dropping into mail queue:
05:06
MD finished with Mail queue:
06:20
First receipt of mail:
06:29
Last returned (bounced) message:
10:14
The fact that it took almost four hours to get all addresses to the outbound
mailer from listserv problaby reflects a bottleneck in our network. The
queuing time was what surprised me. (Now I know to plan for it, or else use
other tools. This data is just FYI, not a complaint.)
This was during an otherwise quiet period. CPU usage was pegged at 99% until the
queue was written (I kept a vmstat log), but other activity on the machine did
not seem to be affected greatly. A 150,000-address mailing took about two
days to queue and deliver, and I'm not planning on repeating that again with
the current hardware setup. <VBG>
Bonnie Scott
Prodigy Services Corp.
bonnie@staff.prodigy.com http://goodstuff.prodigy.com/Lists/
> > 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.
References:
|
|
