xref: /freebsd/contrib/sendmail/src/TUNING (revision f0adf7f5cdd241db2f2c817683191a6ef64a4e95)
1# Copyright (c) 2001-2003 Sendmail, Inc. and its suppliers.
2#	All rights reserved.
3#
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.4.1 2003/02/07 18:19:51 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(`confDELIVERY_MODE', `q')dnl
163define(`confMAX_QUEUE_CHILDREN', `50')dnl
164define(`confMIN_QUEUE_AGE', `27m')dnl
165
166and specify the queuegroup ruleset as follows:
167
168LOCAL_RULESETS
169Squeuegroup
170R$* @ local.domain	$# local
171R$* @ $* one.domain	$# one
172R$* @ $* two.domain	$# two
173R$* @ $*		$# remote
174R$*			$# mqueue
175
176Now it is necessary to control the number of queue runners, which
177is done by MaxQueueChildren.  Starting the daemon with the option
178-q5m assures that the first delivery attempt for each e-mail is
179done within 5 minutes, however, there are also individual queue
180intervals for the queue groups as specified above.  MinQueueAge
181is set to 27 minutes to avoid that entries are run too often.
182
183Notice: if envelope splitting happens due to alias expansion, and
184DeliveryMode is not 'i'nteractive, then only one envelope is sent
185immediately.  The rest (after splitting) are queued up and queue
186runners must come along and take care of them.  Hence it is essential
187that the queue interval is very short.
188
189
190* 1-1 Mass Mailing
191-----------------------------------------------
192
193In this case some program generates e-mails which are sent to
194individual recipients (or at most very few per e-mail).  A simple
195way to achieve high throughput is to set the delivery mode to
196'interactive', turn off the SuperSafe option and make sure that the
197program that generates the mails can deal with mail losses if the
198server loses power.  In no other case should SuperSafe be set to
199'false'.  If these conditions are met, sendmail does not need to
200commit mails to disk but can buffer them in memory which will greatly
201enhance performance, especially compared to normal disk subsystems, e.g.,
202non solid-state disks.
203
204
205* High Volume Mail
206-----------------------------------------------
207
208For high volume mail it is necessary to be able to control the load
209on the system.  Therefore the 'queue' delivery mode should be used,
210and all options related to number of processes and the load should
211be set to reasonable values.  It is important not to accept mail
212faster than it can be delivered otherwise the system will be
213overwhelmed.  Hence RefuseLA should be lower than QueueLA, the number
214of daemon children should probably be lower than the number of queue
215runnners (MaxChildren vs. MaxQueueChildren).  DelayLA is a new option
216in 8.12 which allows delaying connections instead of rejecting them.
217This may result in a smoother load distribution depending on how
218the mails are submitted to sendmail.
219
220
221* Miscellaneous
222-----------------------------------------------
223
224Other options that are interesting to tweak performance are
225(in no particular order):
226
227SuperSafe: if interactive DeliveryMode is used, then this can
228be set to the new value "interactive" in 8.12 to save some disk
229synchronizations which are not really necessary in that mode.
230
231