DeliveryMode=interactive / Performance
Ryan Ordway
is supposed to improve performance, but I've yet to find a reference
as to HOW it improves performance. Could someone point me to some
information on this?
My current situation is I have a somewhat beefy mail creation system
(Sun E4500 / 4x400mHz CPUs / 4GB RAM / Fibre-Channel attached storage
subsystem with read/write caching) that generates mail on-demand
at about 180-190,000 messages/hour. The creation system passes this
mail off to an MTA system (Sun E420R / 4x450mHz / 4GB RAM / FC attached
storage with read/write caching) running Sendmail 8.12.0Beta12 with the
following basic configuration:
OSTYPE(my-solaris)dnl
DOMAIN(my-domain)dnl
FEATURE(`nouucp', `reject')dnl
FEATURE(`use_cw_file', `/etc/mail/localhosts')dnl
FEATURE(`relay_entire_domain')dnl
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access')dnl
FEATURE(`accept_unresolvable_domains')dnl
FEATURE(`accept_unqualified_senders')dnl
FEATURE(`no_default_msa')dnl
undefine(`ALIAS_FILE')dnl
undefine(`confCONNECTION_RATE_THROTTLE')dnl
undefine(`confDOUBLE_BOUNCE_ADDRESS')dnl
undefine(`confERROR_MESSAGE')dnl
undefine(`confMAX_DAEMON_CHILDREN')dnl
undefine(`confMAX_RCPTS_PER_MESSAGE')dnl
undefine(`confMIN_FREE_BLOCKS')dnl
undefine(`confQUEUE_LA')dnl
undefine(`confREFUSE_LA')dnl
define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy,restrictmailq,restrictqr
un,noreceipts')dnl
define(`confCONTROL_SOCKET_NAME', `/etc/mail/.control')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA, Listen=100, M=SAE')dnl
define(`confQUEUE_LA', `100')dnl
define(`confREFUSE_LA', `100')dnl
define(`confDELAY_LA', `0')dnl
define(`confMCI_CACHE_SIZE', `10')dnl
define(`confALLOW_BOGUS_HELO', `False')dnl
define(`confSMTP_LOGIN_MSG', `Der MTA')dnl
define(`confDONT_BLAME_SENDMAIL', `GroupWritableDirPathSafe')dnl
define(`confTO_HOSTSTATUS', `15m')dnl
define(`confHOST_STATUS_DIRECTORY', `hoststatus')dnl
define(`confQUEUE_DIR', `/q/mqueue/q*')dnl
define(`confSAFE_QUEUE', `False')dnl
define(`confTO_COMMAND', `3h')dnl
define(`confTO_ICONNECT', `5s')dnl
define(`confTO_IDENT', `0')dnl
define(`confTO_QUEUERETURN', `2d')dnl
define(`confTO_QUEUEWARN', `8h')dnl
define(`confDONT_INIT_GROUPS', `True')dnl
define(`confDF_BUFFER_SIZE', `30720')dnl
define(`confXF_BUFFER_SIZE', `30720')dnl
define(`confDOMAIN_NAME', `my.domain.name')dnl
define(`confFALLBACK_MX', `my.fallback-mx.host')dnl
MAILER(local)dnl
MAILER(smtp)dnl
LOCAL_RULESETS
And then, the my.fallback-mx.host is an E220R w/ 2x450mHz
CPUs / 2GB RAM and a somewhat slower RAID array for its
logging/queueing.
One problem is that the mail creation system is only opening
3 persistent connections to Sendmail and passing all mail on
these 3 connections. So using DeliveryMode=interactive just
bogs these 3 processes down. In DeliveryMode=background I'm
getting a handoff rate between 25,000-40,000/hour. As the
system fork()s off delivery processes, the mail acceptance rate
slows to a crawl. In DeliveryMode=defer, the rate jumps up to
about 140,000/hour in my last test, which is much better, but
still below what I would like to see as the creation system is
improved and the mail creation rate increases.
I do have a bit of hardware to throw at the problem, I've just
added another CPU board with 2x400mHz/2GB to the E4500 and
I've put together another 4CPU/4GB E420R to act as a second
MTA system. I've put together 2 2CPU/1GB E220R systems to act
as FallbackMX hosts, and I will be moving the current 2CPU/2GB
FallbackMX host to become a 3rd MTA. The creation system will
then be opening connections to all 3 MTAs and passing the
messages over 3x3 SMTP connections.
I've checked out all of the Sendmail performance guides that I
could find, and none of them seem to know anything beyond
8.9.x. The 2nd edition of the O'Reilly book doesn't even know
about 8.9.x, and recommends against using interactive mode except
for testing and command-line usage... in fact it says that the
SMTP daemon cannot use this mode. I've heard mention of Clauss's
performance testing, but I've not been able to find any kind of
documentation. I would greatly appreciate any advice and/or links
to some up-to-date/bleeding-edge Sendmail performance documentation.
Thanks muchly!
Ryan
Claus Aßmann
> I have read in a great deal of posts that DeliveryMode=interactive
> is supposed to improve performance, but I've yet to find a reference
> as to HOW it improves performance. Could someone point me to some
> information on this?
It implements synchronous delivery, hence it doesn't fork() a
sendmail copy for delivery as background mode would do. If you
do that, you can turn off SuperSafe which avoids the costly
meta-data filesystem operation (fsync()). This can result
in substantial throughput improvement depending on your disk
(and OS).
> My current situation is I have a somewhat beefy mail creation system
> (Sun E4500 / 4x400mHz CPUs / 4GB RAM / Fibre-Channel attached storage
> subsystem with read/write caching) that generates mail on-demand
> at about 180-190,000 messages/hour. The creation system passes this
> mail off to an MTA system (Sun E420R / 4x450mHz / 4GB RAM / FC attached
> storage with read/write caching) running Sendmail 8.12.0Beta12 with the
> following basic configuration:
> define(`confHOST_STATUS_DIRECTORY', `hoststatus')dnl
Do you really need that? That increases disk I/O...
> One problem is that the mail creation system is only opening
> 3 persistent connections to Sendmail and passing all mail on
> these 3 connections. So using DeliveryMode=interactive just
Can't you open more? That would be the simplest way to
control the load of the MTA.
> bogs these 3 processes down. In DeliveryMode=background I'm
> getting a handoff rate between 25,000-40,000/hour. As the
> system fork()s off delivery processes, the mail acceptance rate
> slows to a crawl. In DeliveryMode=defer, the rate jumps up to
> about 140,000/hour in my last test, which is much better, but
> still below what I would like to see as the creation system is
> improved and the mail creation rate increases.
If you want the best performance: don't queue...
Of course you need to check the activity on your system,
but unless you have a high-end disk system it will be the
bottleneck.
If you have a solid-state disk (or you simply don't use
the queue) then network I/O is most likely the next candidate,
maybe DNS lookups.
> I've checked out all of the Sendmail performance guides that I
> could find, and none of them seem to know anything beyond
> 8.9.x.
sendmail/TUNING comes with 8.12.
Comments are welcome.
> I've heard mention of Clauss's
^
> performance testing, but I've not been able to find any kind of
> documentation.
It's only in the archive of the newsgroup; I never officially
published the numbers.
First of all: do some measurements (iostat, vmstat, ...)
to figure out where the bottleneck on your current system is.
Then you can apply the appropriate actions.
Without those data I can only point you to the generic
documentation.
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.