J C;
Thanks for the detailed answer. Read on:
Please see the FAQ:
http://www.python.org/cgi-bin/faqw-mm.py
Read it well and carefully. Follow ALL the instructions. Loosely:
Will do. Thanks.
Buy some RAM. Stuff your box full of it. Get up to the couple Gig+
range if you can (I don't know Macs well to know how easy that is).
Don't even attempt this without at least 512Meg (1Gig will be much
better).
It's already maxed out at 768 mb. But another off list suggestion
was that I would want to get a dedicated box for this anyway, since
no matter how fast I got it to go, it would still take a while and
would block other activities in the meantime.
Get a new disk for /var/spool/postfix and another separate disk for
/var/log. If you have the opportunity, make the spool disk faster. At
this point don't worry about IDE vs SCSI.
Very interesting suggestion, and disks are sooo cheap now.
If you can smarthost all outbound traffic to a different system from
your Mailman system. Set it up similarly as above/below (distinct
spindle for spool and log, postfix config etc). This simple step
would make handling this sort of load almost easy. If you can't do
this, check with your ISP and see if they'd be willing to smarthost
for you. Many will.
"smarthost" is a new term for me. I'll look it up.
Go straight to Mailman v2.1. Don't bother with 2.0.
Already there.
As a comparable under Postfix on a dual PII-333 with 512Meg RAM
sitting on a couple T3s and a T1 I can sustain 1,400 deliveries a
minute. You should be comfortably able to sustain at least half that
given that you've a slightly less muscled box and your outbound
bandwidth situation is likely skinnier.
As this is not delivering time sensitive information, these
expectations are encouraging.
Given a reasonable distribution of slow MX'es (which is a silly
meaningless unrelative thing to say, but hey) that would mean that
you'd drain the majority of the queue down to the slow MXes in about
an hour (accounting for IO and spool contention). If you want to use
your system for anything else during that time (expect system loads in
the 20 - 30 range for the majority of that time) you can reduce the
number of queue runners or throw in some bandwidth profiling, but note
that that will extend drain time non-linearly.
That's a good hint. If this goes through, I might use this as a
dedicated list server and try to recruit other list clients and give
them specific time slots for sending messages to keep them spaced
apart. Or maybe it will be a dedicated mail server, but require them
to send the messages late at night.
Be prepared for a fairly extensive period of fiddling getting this
really happy. You're not up in the range where things get really
sensitive, but you're getting there. Some care and discretion will be
required.
Thanks again for your excellent suggestions.
Rob
------------------------------------------------------
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: archive@jab.org
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
