TUNING revision 94334
138581Sobrien# Copyright (c) 2001-2002 Sendmail, Inc. and its suppliers.
238581Sobrien#	All rights reserved.
338581Sobrien#
4# By using this file, you agree to the terms and conditions set
5# forth in the LICENSE file which can be found at the top level of
6# the sendmail distribution.
7#
8#	$Id: TUNING,v 1.18 2002/03/03 03:38:21 ca Exp $
9#
10
11********************************************
12** This is a DRAFT, comments are welcome! **
13********************************************
14
15
16If the default configuration of sendmail does not achieve the
17required performance, there are several configuration options that
18can be changed to accomplish higher performance.  However, before
19those options are changed it is necessary to understand why the
20performance is not as good as desired.  This may also involve hardware
21and software (OS) configurations which are not extensively explored
22in this document.  We assume that your system is not limited by
23network bandwidth because optimizing for this situation is beyond
24the scope of this guide.  In almost all other cases performance will
25be limited by disk I/O.
26
27
28This text assumes that all options which are mentioned here are
29familiar to the reader, they are explained in the Sendmail Installation
30and Operations Guide; doc/op/op.txt.
31
32There are basically three different scenarios which are treated
33in the following:
34* Mailing Lists and Large Aliases (1-n Mailing)
35* 1-1 Mass Mailing
36* High Volume Mail
37
38Depending on your requirements, these may need different options
39to optimize sendmail for the particular purpose.  It is also possible
40to configure sendmail to achieve good performance in all cases, but
41it will not be optimal for any specific purpose.  For example, it
42is non-trivival to combine low latency (fast delivery of incoming
43mail) with high overall throughput.
44
45Before we explore the different scenarios, a basic discussion about
46disk I/O, delivery modes, and queue control is required.
47
48
49* Disk I/O
50-----------------------------------------------
51
52In general mail will be written to disk up before a delivery attempt
53is made.  This is required for reliability and should only be changed
54in a few specific cases that are mentioned later on.  To achieve
55better disk I/O performance the queue directories can be spread
56over several disks to distribute the load.  This is some basic tuning
57that should be done in all cases where the I/O speed of a single
58disk is exceeded, which is true for almost every high-volume
59situation except if a special disk subsystem with large (NV)RAM
60buffer is used.
61
62Depending on your OS there might be ways to speed up I/O, e.g.,
63using softupdates or turning on the noatime mount option.  If this
64is done make sure the filesystem is still reliable, i.e., if fsync()
65returns without an error, the file has really been committed to
66disk.
67
68
69* Queueing Strategies and DeliveryMode
70-----------------------------------------------
71
72There are basically three delivery modes:
73
74background: incoming mail will be immediately delivered by a new process
75interactive: incoming mail will be immediately delivered by the same process
76queue: incoming mail will be queued and delivered by a queue runner later on
77
78The first offers the lowest latency without the disadvantage of the
79second, which keep the connection from the sender open until the
80delivery to the next hop succeeded or failed.  However, it does not
81allow for a good control over the number of delivery processes other
82than limiting the total number of direct children of the daemon
83processes (MaxChildren) or by load control options (RefuseLA,
84DelayLA).  Moreover, it can't make as good use as 'queue' mode can
85for connection caching.
86
87Interactive DeliveryMode should only be used in rare cases, e.g.,
88if the delivery time to the next hop is a known quantity or if the
89sender is under local control and it does not matter if it has to
90wait for delivery.
91
92Queueing up e-mail before delivery is done by a queue runner allows
93the best load control but does not achieve as low latency as the
94other two modes.  However, this mode is probably also best for
95concurrent delivery since the number of queue runners can be specified
96on a queue group basis.  Persistent queue runners (-qp) can be used
97to minimize the overhead for creating processes because they just
98sleep for the specified interval (which shold be short) instead of
99exiting after a queue run.
100
101
102* Queue Groups
103-----------------------------------------------
104
105In most situations disk I/O is a bottleneck which can be mitigated
106by spreading the load over several disks.  This can easily be achieved
107with different queue directories.  sendmail 8.12 introduces queue
108groups which are collections of queue directories with similar
109properties, i.e., number of processes to run the queues in the
110group, maximum number of recipients within an e-mail (envelope),
111etc.  Queue groups allow control over the behaviour of different
112queues.  Depending on the setup, it is usually possible to have
113several queue runners delivering mails concurrently which should
114increase throughput.  The number of queue runners can be controlled
115per queue group (Runner=) and overall (MaxQueueChildren).
116
117
118* DNS Lookups
119-----------------------------------------------
120
121sendmail performs by default host name canonifications by using
122host name lookups.  This process is meant to replace unqualified
123host name with qualified host names, and CNAMEs with the non-aliased
124name.  However, these lookups can take a while for large address
125lists, e.g., mailing lists.  If you can assure by other means that
126host names are canonical, you should use
127
128		FEATURE(`nocanonify', `canonify_hosts')
129
130in your .mc file.  For further information on this feature and
131additional options see cf/README.  If sendmail is invoked directly
132to send e-mail then either the -G option should be used or
133
134	define(`confDIRECT_SUBMISSION_MODIFIERS', `C')
135
136should be added to the .mc file.
137
138
139* Mailing Lists and Large Aliases (1-n Mailing)
140-----------------------------------------------
141
142Before 8.12 sendmail delivers an e-mail sequentially to all its
143recipients.  For mailing lists or large aliases the overall delivery
144time can be substantial, especially if some of the recipients are
145located at hosts that are slow to accept e-mail.  Some mailing list
146software therefore "split" up e-mails into smaller pieces with
147fewer recipients.  sendmail 8.12 can do this itself, either across
148queue groups or within a queue directory.  The latter is controlled
149by the 'r=' field of a queue group declaration.
150
151Let's assume a simple example: a mailing lists where most of
152the recipients are at three domains: the local one (local.domain)
153and two remotes (one.domain, two.domain) and the rest is splittered
154over several other domains.  For this case it is useful to specify
155three queue groups:
156
157QUEUE_GROUP(`local', `P=/var/spool/mqueue/local, F=f, R=2, I=1m')dnl
158QUEUE_GROUP(`one', `P=/var/spool/mqueue/one, F=f, r=50, R=3')dnl
159QUEUE_GROUP(`two', `P=/var/spool/mqueue/two, F=f, r=30, R=4')dnl
160QUEUE_GROUP(`remote', `P=/var/spool/mqueue/remote, F=f, r=5, R=8, I=2m')dnl
161define(`ESMTP_MAILER_QGRP', `remote')dnl
162define(`confSPLIT_ACROSS_QUEUEGROUPS', `True')dnl
163define(`confDELIVERY_MODE', `q')dnl
164define(`confMAX_QUEUE_CHILDREN', `50')dnl
165define(`confMIN_QUEUE_AGE', `27m')dnl
166
167and specify the queuegroup ruleset as follows:
168
169LOCAL_RULESETS
170Squeuegroup
171R$* @ local.domain	$# local
172R$* @ $* one.domain	$# one
173R$* @ $* two.domain	$# two
174R$* @ $*		$# remote
175R$*			$# mqueue
176
177Now it is necessary to control the number of queue runners, which
178is done by MaxQueueChildren.  Starting the daemon with the option
179-q5m assures that the first delivery attempt for each e-mail is
180done within 5 minutes, however, there are also individual queue
181intervals for the queue groups as specified above.  MinQueueAge
182is set to 27 minutes to avoid that entries are run too often.
183
184Notice: if envelope splitting happens due to alias expansion, and
185DeliveryMode is not 'i'nteractive, then only one envelope is sent
186immediately.  The rest (after splitting) are queued up and queue
187runners must come along and take care of them.  Hence it is essential
188that the queue interval is very short.
189
190
191* 1-1 Mass Mailing
192-----------------------------------------------
193
194In this case some program generates e-mails which are sent to
195individual recipients (or at most very few per e-mail).  A simple
196way to achieve high throughput is to set the delivery mode to
197'interactive', turn off the SuperSafe option and make sure that the
198program that generates the mails can deal with mail losses if the
199server loses power.  In no other case should SuperSafe be set to
200'false'.  If these conditions are met, sendmail does not need to
201commit mails to disk but can buffer them in memory which will greatly
202enhance performance, especially compared to normal disk subsystems, e.g.,
203non solid-state disks.
204
205
206* High Volume Mail
207-----------------------------------------------
208
209For high volume mail it is necessary to be able to control the load
210on the system.  Therefore the 'queue' delivery mode should be used,
211and all options related to number of processes and the load should
212be set to reasonable values.  It is important not to accept mail
213faster than it can be delivered otherwise the system will be
214overwhelmed.  Hence RefuseLA should be lower than QueueLA, the number
215of daemon children should probably be lower than the number of queue
216runnners (MaxChildren vs. MaxQueueChildren).  DelayLA is a new option
217in 8.12 which allows delaying connections instead of rejecting them.
218This may result in a smoother load distribution depending on how
219the mails are submitted to sendmail.
220
221
222* Miscellaneous
223-----------------------------------------------
224
225Other options that are interesting to tweak performance are
226(in no particular order):
227
228SuperSafe: if interactive DeliveryMode is used, then this can
229be set to the new value "interactive" in 8.12 to save some disk
230synchronizations which are not really necessary in that mode.
231
232