contrib/sendmail-8.13.4/sendmail/TUNING

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