Re: sendmail is slow for mass mail
Here's a few things to try...
1) Try multiple queues... that will help greately. Also sort your queues
by host (to insure that your sendmail doesn't keep reconnecting to AOL
2) Move BIND to a dedecated server, unless you've got an obscene ammount
of RAM. Don't make that machine (the DNS machine) authoritative for any
domains. Probably best to not point any other clients at it either.
3) What's your hard drive setup? If /var/spool and /var/log are on the
same disk... you're hurting. Seperate the spools from the log dir.
4) Tune /etc/syslog.conf to only log errors to the syslog.. all other
mail logs should go to /var/log/mail.info and mail.err (or whatever).
Also, don't synch the mail log files (put a "-" in front of the
5) Try toggling the Host Status option on and off. Also make sure the
status directory is on a fast disk. If your status/com subdirectory gets
huge (mine sure does), you may want to consider putting it on something
other than an ext2 fs.
5) Tune your timeouts! Some suggested changes (some are particular for a
server that's heavily loaded on outgoing only):
ConnectionCacheTimeout = 30 (or less... default is 5 min... if your
queue is sorted by destination, you're wasting time holding the SMTP
dialogue open for five minutes).
QueueTimeout: If this is a fairly stable mailing list, you may want
to dump messages that have sat for a while... your call. May also want
to change retry factor, to de-prioritize old messages.
TimeoutConnect = 1m (if we can't connect within 1 minute, the host is
probably down or temporarily unreachable... don't wait 90min).
TimoutIconnect = 10s (Be real picky on the Initial connection...
let's get mail out to the easiest hosts first.)
6) Check some metrics to see where else you're bottled up. Run MRTG or
something to watch capacity on your connection. Check top every now and
then to see what your memory usage is (if you insist on leaving BIND on
that box be sure BIND never has to swap...).
7) IDE or SCSI drives? If you're running off of one or two poky old IDE
drives you're in tough shape... spring for a hardware RAID card and a
couple of SCSI drives. Or... if you're only doing outgoing email, and
you could tolerate losing a couple of messages in the event of a disk
crash (not too unlikely... losing a few messages shouldn't hurt as long
as you can get back up quickly), you can set up the drives in RAID 0
(striping) for a wicked fast disk setup.
8) Do you really need SASL on a mailing list server? Just checking...
That's a load to dig into, but it should get you a start on things. Good
> I have a sendmail installation using sendmail_8.11.3+8.12.0.Beta5-4_i386.deb
> + SASL on a linux 2.4.3-pre4 i686.
> I am attempting to process very high volume mailingslists (10-100K
> multiples) on this server.
> My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate.
> First, during the initial esmtp dialogue, sendmail checks each and every
> recipient address and after 1 or more seconds it says:
> "250 2.1.5 <email@example.com>... Recipient ok"
> for each recipient. Unfortunately, there are 100K recipients,
> and my MUA has to maintain that open connection for hours.
> There must be a better way!
> Second, once the dialogue is complete, sendmail puts the whole
> envelope into the queue. Then, by drips and drabs, sendmail selects a handfull
> of recipients and sends them the email. It does this during every
> queue-flush-run (every 10 minutes) in my case. How can I get sendmail
> to process the whole envelope at once? Is it supposed to take days to
> process large mailinglists? What am I doing wrong?
> BTW: this machine has its own BIND.
> Also, I won't use qmail because I have too much invested in sendmail at this
> point, and I dislike the DJB's licensing terms.
> Jean-Paul Stewart
> Senior Systems Administrator
> CarbonMedia, Inc.
> 114 East 25th Street, Eighth Floor
> New York, NY 10010
> Phone: 212.253.7180
> Fax: 212.253.8467
> For my PGP/GPG public key:
> `finger firstname.lastname@example.org'
> Part 1.2Type: application/pgp-signature
ETN Systems Inc.