On Fri, 28 Dec 2001 17:59:09 PST, Kamal Kamra <[log in to unmask]>  said:

> We have a ListServ installed on Solaris 8 and it is working fine. It has
> sendmail 8.12 installed on it and it is working OK. But we are almost at a
> point where sendmail is no longer able to handle the mail traffic so we are
> deciding to migrate to postfix. As part of testing postfix with listserv

Yow.

How much mail are you guys *running*?  I've been managing up to 1M
RCPT TO: per day on an old IBM RS6000 (133mz 604 processor, 256M
memory) with fairly good delivery times and low system load averages
(if the load average is staying over 3-4, or mail takes more than a
minute, I have a problem).  This weekend, I'm moving to a "new" box
(4x200mz 604e, 2G memory), and should be able to take off the low
value of MaxDaemonChildren I needed to keep from thrashing in 256M,
so things should go even faster.  1M messages/hour is certainly
achievable with Sendmail - I could say how much higher than that,
but *that* number is under an NDA (but it's a LOT higher ;).

Quick things to speed stuff up:

1) Somebody else mentioned SMTP_FORWARD_1 - this does wonders on the local
machine as well.

2) Include 'FEATURE(nocanonify)' in your sendmail.mc - this cuts out a
DNS lookup at a bad place for throughput.  I've measured a 5x-6x speedup
in message acceptance rate just by doing this.

3) The sendmail memory leaks are fixed.  With Sendmail 8.12, it works just
fine to run with MAXBSMTP="1000" in your go.sys file (and sendmail will do
any envelope splitting as needed once it receives it).  You could probably
go over 1000, but it will only help when you have more than 1,000 recipients
to a posting.

4) If memory permits, run a local caching-only nameserver.

5) Sendmail still has some performance issues with large queues.  You may want
to look at the contrib/qtool.pl to manage multiple queues.  The basic
theory:

5a) The main sendmail queues stuff into /var/spool/mqueue

5b) Several times an hour, you have cron run the command:
'qtool -s 3600 /var/spool/mqueue2 /var/spool/mqueue'.  This will re-queue
mail that couldn't be delivered immediately to get it out of the way of
the main sendmail.

5c) You run a second sendmail: "/usr/lib/sendmail -q30m -oQ/var/spool/mqueue2"
to keep re-trying the mail that didn't deliver on the first try or two.

Our setup is a *bit* more complicated, but that's the basic idea and will
get you to fairly high throughput levels.  If you're running more than
several million messages/day, it gets more interesting, but the concept
remains the same.  A not-covered-by-NDA hint to make Sendmail's directory
searching go faster:

5d) #!/bin/ksh
    for i in 1 2 3 4 5;
    do
      newdir=/var/spool/mqueue/dir${1}
      mkdir $newdir
      mkdir $newdir/qf
      mkdir $newdir/df
      mkdir $newdir/xf
    done
(and then put this in your sendmail.mc:

define(`QUEUE_DIR',`/var/spool/mqueue/dir*')

Of course, this makes the qtool stuff a bit more interesting.. ;)

6) Depending on your environment, you may be able to take advantage of
the sendmail 'queue groups' features added in 8.12 - this made quite a
difference for us, as I was able to segregate about 70% of our mail into
several high-throughput queue groups with a high recipients/envelope ratio,
and run mail to "the rest of the internet" with a low number of recipients
per envelope (so one hung host wouldn't delay everybody).

This stuff works.  I should know, I was probably the guy who found the
most bugs in the queue group and envelope splitting code during the 8.12.0
alpha/beta testing. ;)

If you need more hints than that, let me know.  Points 1-3 could by themselves
get a 10x speedup for you, and 5a-c are well worth the work of implementing
as well if you have large queues.
--
                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech