1# Copyright (c) 2001-2003, 2014 Proofpoint, 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.22 2013-11-22 20:51:54 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-trivial 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 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 keeps 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 should 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 138Note: starting with 8.15, sendmail will not ignore temporary map 139lookup failures during header rewriting, which means that DNS lookup 140problems even for headers will cause messages to stay in the queue. 141Hence it is strongly suggested to use the nocanonify feature; 142at least turning it on for the MTA, but maybe disabling it for the 143MSA, i.e., use Modifiers for DaemonPortOptions accordingly. 144As a last resort, it is possible to override the host map to ignore 145temporary failures, e.g., 146Khost host -t 147However, this can cause inconsistent header rewriting. 148 149 150* Mailing Lists and Large Aliases (1-n Mailing) 151----------------------------------------------- 152 153Before 8.12 sendmail would deliver an e-mail sequentially to all its 154recipients. For mailing lists or large aliases the overall delivery 155time can be substantial, especially if some of the recipients are 156located at hosts that are slow to accept e-mail. Some mailing list 157software therefore "split" up e-mails into smaller pieces with 158fewer recipients. sendmail 8.12 can do this itself, either across 159queue groups or within a queue directory. The latter is controlled 160by the 'r=' field of a queue group declaration. 161 162Let's assume a simple example: a mailing list where most of the 163recipients are at three domains: the local one (local.domain) and 164two remotes (one.domain, two.domain) and the rest is splittered 165over several other domains. For this case it is useful to specify 166three queue groups: 167 168QUEUE_GROUP(`local', `P=/var/spool/mqueue/local, F=f, R=2, I=1m')dnl 169QUEUE_GROUP(`one', `P=/var/spool/mqueue/one, F=f, r=50, R=3')dnl 170QUEUE_GROUP(`two', `P=/var/spool/mqueue/two, F=f, r=30, R=4')dnl 171QUEUE_GROUP(`remote', `P=/var/spool/mqueue/remote, F=f, r=5, R=8, I=2m')dnl 172define(`ESMTP_MAILER_QGRP', `remote')dnl 173define(`confDELIVERY_MODE', `q')dnl 174define(`confMAX_QUEUE_CHILDREN', `50')dnl 175define(`confMIN_QUEUE_AGE', `27m')dnl 176 177and specify the queuegroup ruleset as follows: 178 179LOCAL_RULESETS 180Squeuegroup 181R$* @ local.domain $# local 182R$* @ $* one.domain $# one 183R$* @ $* two.domain $# two 184R$* @ $* $# remote 185R$* $# mqueue 186 187Now it is necessary to control the number of queue runners, which 188is done by MaxQueueChildren. Starting the daemon with the option 189-q5m assures that the first delivery attempt for each e-mail is 190done within 5 minutes, however, there are also individual queue 191intervals for the queue groups as specified above. MinQueueAge 192is set to 27 minutes to avoid that entries are run too often. 193 194Notice: if envelope splitting happens due to alias expansion, and 195DeliveryMode is not 'i'nteractive, then only one envelope is sent 196immediately. The rest (after splitting) are queued up and queue 197runners must come along and take care of them. Hence it is essential 198that the queue interval is very short. 199 200 201* 1-1 Mass Mailing 202----------------------------------------------- 203 204In this case some program generates e-mails which are sent to 205individual recipients (or at most very few per e-mail). A simple 206way to achieve high throughput is to set the delivery mode to 207'interactive', turn off the SuperSafe option and make sure that the 208program that generates the mails can deal with mail losses if the 209server loses power. In no other case should SuperSafe be set to 210'false'. If these conditions are met, sendmail does not need to 211commit mails to disk but can buffer them in memory which will greatly 212enhance performance, especially compared to normal disk subsystems, e.g., 213non solid-state disks. 214 215 216* High Volume Mail 217----------------------------------------------- 218 219For high volume mail it is necessary to be able to control the load 220on the system. Therefore the 'queue' delivery mode should be used, 221and all options related to number of processes and the load should 222be set to reasonable values. It is important not to accept mail 223faster than it can be delivered; otherwise the system will be 224overwhelmed. Hence RefuseLA should be lower than QueueLA, the number 225of daemon children should probably be lower than the number of queue 226runners (MaxChildren vs. MaxQueueChildren). DelayLA is a new option 227in 8.12 which allows delaying connections instead of rejecting them. 228This may result in a smoother load distribution depending on how 229the mails are submitted to sendmail. 230 231 232* Miscellaneous 233----------------------------------------------- 234 235Other options that are interesting to tweak performance are 236(in no particular order): 237 238SuperSafe: if interactive DeliveryMode is used, then this can 239be set to the new value "interactive" in 8.12 to save some disk 240synchronizations which are not really necessary in that mode. 241 242