Apparently vger is doing 17 deliveries per second---not directly to the
recipients, but through a small number of cooperating relays.
They say that vger is having trouble with this load: delays of an hour
or more. But they don't say why. Is zmailer using too much memory for
the large lists? Is majordomo using too much CPU time? What resources
are turning into bottlenecks, and how are they being used?
If zmailer is a contributing factor, there are two obvious ways to get
it out of the picture:
(1) Use qmail to deliver directly to recipients.
A concurrency of 255 will handle around 30 deliveries per second,
depending on recipient location; consume 20 or 30 megabytes of
memory; and generate perhaps one megabit of traffic per second,
depending on message size.
(2) Use mini-qmail to deliver to QMQP servers on the relays.
QMQP is designed for fast remote message queueing. It typically
handles 100 recipients per second---through a 28.8 modem! From
this perspective, vger's current load is trivial.
They could start by delivering just a few of their lists through qmail,
to see how good the performance is, and then build up to the entire
outgoing mail load.
Edward S. Marshall writes:
> Surely you jest? Do you have -any- idea how many deliveries, plus cvs
> sessions, vger.rutgers.edu deals with daily? Sorry, but the system
> handling the QMail mailing list doesn't even come close to that level of
> throughput load.
Actually, the qmail mailing list often handles 20 deliveries per second
directly to recipients, at a concurrency of 120. It rarely has more than
a few thousand deliveries to do at once, but there's no scaling problem.
That machine is also running a CPU-intensive computation and a
network-intensive survey of several hundred million IP addresses.
---Dan
