TUNING revision 90792
1255767Sdes# Copyright (c) 2001 Sendmail, Inc. and its suppliers. 2124208Sdes# All rights reserved. 398937Sdes# 4126274Sdes# By using this file, you agree to the terms and conditions set 598937Sdes# forth in the LICENSE file which can be found at the top level of 6126274Sdes# the sendmail distribution. 7126274Sdes# 8126274Sdes# $Id: TUNING,v 1.16 2001/08/19 21:03:38 gshapiro Exp $ 998937Sdes# 10126274Sdes 11126274Sdes******************************************** 12126274Sdes** This is a DRAFT, comments are welcome! ** 13126274Sdes******************************************** 14126274Sdes 15126274Sdes 16126274SdesIf the default configuration of sendmail does not achieve the 1798937Sdesrequired performance, there are several configuration options that 1898937Sdescan be changed to accomplish higher performance. However, before 1998937Sdesthose options are changed it is necessary to understand why the 2098937Sdesperformance is not as good as desired. This may also involve hardware 2198937Sdesand software (OS) configurations which are not extensively explored 22124208Sdesin this document. We assume that your system is not limited by 2398937Sdesnetwork bandwidth because optimizing for this situation is beyond 24124208Sdesthe scope of this guide. In almost all other cases performance will 2598937Sdesbe limited by disk I/O. 2698937Sdes 2798937Sdes 2898937SdesThis text assumes that all options which are mentioned here are 2998937Sdesfamiliar to the reader, they are explained in the Sendmail Installation 3098937Sdesand Operations Guide; doc/op/op.txt. 31124208Sdes 3298937SdesThere are basically three different scenarios which are treated 3398937Sdesin the following: 3498937Sdes* Mailing Lists and Large Aliases (1-n Mailing) 35124208Sdes* 1-1 Mass Mailing 3698937Sdes* High Volume Mail 3798937Sdes 3898937SdesDepending on your requirements, these may need different options 39124208Sdesto optimize sendmail for the particular purpose. It is also possible 4098937Sdesto configure sendmail to achieve good performance in all cases, but 4198937Sdesit will not be optimal for any specific purpose. For example, it 4298937Sdesis non-trivival to combine low latency (fast delivery of incoming 43124208Sdesmail) with high overall throughput. 4498937Sdes 4598937SdesBefore we explore the different scenarios, a basic discussion about 4698937Sdesdisk I/O, delivery modes, and queue control is required. 47124208Sdes 4898937Sdes 4998937Sdes* Disk I/O 5098937Sdes----------------------------------------------- 51124208Sdes 5298937SdesIn general mail will be written to disk up before a delivery attempt 5398937Sdesis made. This is required for reliability and should only be changed 54240075Sdesin a few specific cases that are mentioned later on. To achieve 55240075Sdesbetter disk I/O performance the queue directories can be spread 56240075Sdesover several disks to distribute the load. This is some basic tuning 5798937Sdesthat should be done in all cases where the I/O speed of a single 5898937Sdesdisk is exceeded, which is true for almost every high-volume 5998937Sdessituation except if a special disk subsystem with large (NV)RAM 6098937Sdesbuffer is used. 6198937Sdes 6298937SdesDepending on your OS there might be ways to speed up I/O, e.g., 6398937Sdesusing softupdates or turning on the noatime mount option. If this 6498937Sdesis done make sure the filesystem is still reliable, i.e., if fsync() 6598937Sdesreturns without an error, the file has really been committed to 66124208Sdesdisk. 6798937Sdes 6898937Sdes 6998937Sdes* Queueing Strategies and DeliveryMode 70124208Sdes----------------------------------------------- 7198937Sdes 7298937SdesThere are basically three delivery modes: 73113908Sdes 74113908Sdesbackground: incoming mail will be immediately delivered by a new process 75113908Sdesinteractive: incoming mail will be immediately delivered by the same process 76113908Sdesqueue: incoming mail will be queued and delivered by a queue runner later on 77113908Sdes 78113908SdesThe first offers the lowest latency without the disadvantage of the 79113908Sdessecond, which keep the connection from the sender open until the 80124208Sdesdelivery to the next hop succeeded or failed. However, it does not 81113908Sdesallow for a good control over the number of delivery processes other 8298937Sdesthan limiting the total number of direct children of the daemon 83248619Sdesprocesses (MaxChildren) or by load control options (RefuseLA, 84248619SdesDelayLA). Moreover, it can't make as good use as 'queue' mode can 85248619Sdesfor connection caching. 86248619Sdes 87124208SdesInteractive DeliveryMode should only be used in rare cases, e.g., 88124208Sdesif the delivery time to the next hop is a known quantity or if the 89124208Sdessender is under local control and it does not matter if it has to 90124208Sdeswait for delivery. 91124208Sdes 92124208SdesQueueing up e-mail before delivery is done by a queue runner allows 93124208Sdesthe best load control but does not achieve as low latency as the 94124208Sdesother two modes. However, this mode is probably also best for 95128456Sdesconcurrent delivery since the number of queue runners can be specified 96240075Sdeson a queue group basis. Persistent queue runners (-qp) can be used 97128456Sdesto minimize the overhead for creating processes because they just 98128456Sdessleep for the specified interval (which shold be short) instead of 99124208Sdesexiting after a queue run. 100124208Sdes 101124208Sdes 102124208Sdes* Queue Groups 103124208Sdes----------------------------------------------- 104124208Sdes 105221420SdesIn most situations disk I/O is a bottleneck which can be mitigated 106221420Sdesby spreading the load over several disks. This can easily be achieved 107221420Sdeswith different queue directories. sendmail 8.12 introduces queue 108221420Sdesgroups which are collections of queue directories with similar 109248619Sdesproperties, i.e., number of processes to run the queues in the 110248619Sdesgroup, maximum number of recipients within an e-mail (envelope), 111248619Sdesetc. Queue groups allow control over the behaviour of different 112248619Sdesqueues. Depending on the setup, it is usually possible to have 113255767Sdesseveral queue runners delivering mails concurrently which should 114255767Sdesincrease throughput. The number of queue runners can be controlled 115255767Sdesper queue group (Runner=) and overall (MaxQueueChildren). 116255767Sdes 117255767Sdes 118255767Sdes* DNS Lookups 119255767Sdes----------------------------------------------- 120255767Sdes 121255767Sdessendmail performs by default host name canonifications by using 122255767Sdeshost name lookups. This process is meant to replace unqualified 123255767Sdeshost name with qualified host names, and CNAMEs with the non-aliased 124255767Sdesname. However, these lookups can take a while for large address 12598937Sdeslists, 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 located 145at hosts that are slow to accept e-mail. Some mailing list software 146therefore "split" up e-mails into smaller pieces with fewer recipients. 147sendmail 8.12 can do this itself, either across queue groups or 148within a queue directory. For the former the option SplitAcrossQueueGroups 149option must be set, the latter is controlled by the 'r=' field of 150a queue group declaration. 151 152Let's assume a simple example: a mailing lists where most of 153the recipients are at three domains: the local one (local.domain) 154and two remotes (one.domain, two.domain) and the rest is splittered 155over several other domains. For this case it is useful to specify 156three queue groups: 157 158QUEUE_GROUP(`local', `P=/var/spool/mqueue/local, F=f, R=2, I=1m')dnl 159QUEUE_GROUP(`one', `P=/var/spool/mqueue/one, F=f, r=50, R=3')dnl 160QUEUE_GROUP(`two', `P=/var/spool/mqueue/two, F=f, r=30, R=4')dnl 161QUEUE_GROUP(`remote', `P=/var/spool/mqueue/remote, F=f, r=5, R=8, I=2m')dnl 162define(`ESMTP_MAILER_QGRP', `remote')dnl 163define(`confSPLIT_ACROSS_QUEUEGROUPS', `True')dnl 164define(`confDELIVERY_MODE', `q')dnl 165define(`confMAX_QUEUE_CHILDREN', `50')dnl 166define(`confMIN_QUEUE_AGE', `27m')dnl 167 168and specify the queuegroup ruleset as follows: 169 170LOCAL_RULESETS 171Squeuegroup 172R$* @ local.domain $# local 173R$* @ $* one.domain $# one 174R$* @ $* two.domain $# two 175R$* @ $* $# remote 176R$* $# mqueue 177 178Now it is necessary to control the number of queue runners, which 179is done by MaxQueueChildren. Starting the daemon with the option 180-q5m assures that the first delivery attempt for each e-mail is 181done within 5 minutes, however, there are also individual queue 182intervals for the queue groups as specified above. MinQueueAge 183is set to 27 minutes to avoid that entries are run too often. 184 185Notice: if envelope splitting happens due to alias expansion, and 186DeliveryMode is not 'i'nteractive, then only one envelope is sent 187immediately. The rest (after splitting) are queued up and queue 188runners must come along and take care of them. Hence it is essential 189that the queue interval is very short. 190 191 192* 1-1 Mass Mailing 193----------------------------------------------- 194 195In this case some program generates e-mails which are sent to 196individual recipients (or at most very few per e-mail). A simple 197way to achieve high throughput is to set the delivery mode to 198'interactive', turn off the SuperSafe option and make sure that the 199program that generates the mails can deal with mail losses if the 200server loses power. In no other case should SuperSafe be set to 201'false'. If these conditions are met, sendmail does not need to 202commit mails to disk but can buffer them in memory which will greatly 203enhance performance, especially compared to normal disk subsystems, e.g., 204non solid-state disks. 205 206 207* High Volume Mail 208----------------------------------------------- 209 210For high volume mail it is necessary to be able to control the load 211on the system. Therefore the 'queue' delivery mode should be used, 212and all options related to number of processes and the load should 213be set to reasonable values. It is important not to accept mail 214faster than it can be delivered otherwise the system will be 215overwhelmed. Hence RefuseLA should be lower than QueueLA, the number 216of daemon children should probably be lower than the number of queue 217runnners (MaxChildren vs. MaxQueueChildren). DelayLA is a new option 218in 8.12 which allows delaying connections instead of rejecting them. 219This may result in a smoother load distribution depending on how 220the mails are submitted to sendmail. 221 222 223* Miscellaneous 224----------------------------------------------- 225 226Other options that are interesting to tweak performance are 227(in no particular order): 228 229SuperSafe: if interactive DeliveryMode is used, then this can 230be set to the new value "interactive" in 8.12 to save some disk 231synchronizations which are not really necessary in that mode. 232 233