TUNING revision 285303
1238438Sdteske# Copyright (c) 2001-2003, 2014 Proofpoint, Inc. and its suppliers. 2238438Sdteske# All rights reserved. 3249746Sdteske# 4252980Sdteske# By using this file, you agree to the terms and conditions set 5238438Sdteske# forth in the LICENSE file which can be found at the top level of 6238438Sdteske# the sendmail distribution. 7238438Sdteske# 8238438Sdteske# $Id: TUNING,v 1.22 2013-11-22 20:51:54 ca Exp $ 9238438Sdteske# 10238438Sdteske 11238438Sdteske******************************************** 12238438Sdteske** This is a DRAFT, comments are welcome! ** 13238438Sdteske******************************************** 14238438Sdteske 15238438Sdteske 16252987SdteskeIf the default configuration of sendmail does not achieve the 17238438Sdteskerequired performance, there are several configuration options that 18238438Sdteskecan be changed to accomplish higher performance. However, before 19238438Sdteskethose options are changed it is necessary to understand why the 20252987Sdteskeperformance is not as good as desired. This may also involve hardware 21238438Sdteskeand software (OS) configurations which are not extensively explored 22238438Sdteskein this document. We assume that your system is not limited by 23238438Sdteskenetwork bandwidth because optimizing for this situation is beyond 24238438Sdteskethe scope of this guide. In almost all other cases performance will 25238438Sdteskebe limited by disk I/O. 26238438Sdteske 27238438Sdteske 28238438SdteskeThis text assumes that all options which are mentioned here are 29238438Sdteskefamiliar to the reader, they are explained in the Sendmail Installation 30238438Sdteskeand Operations Guide; doc/op/op.txt. 31240684Sdteske 32240684SdteskeThere are basically three different scenarios which are treated 33244675Sdteskein the following: 34240684Sdteske* Mailing Lists and Large Aliases (1-n Mailing) 35240684Sdteske* 1-1 Mass Mailing 36240684Sdteske* High Volume Mail 37238438Sdteske 38240684SdteskeDepending on your requirements, these may need different options 39238438Sdtesketo optimize sendmail for the particular purpose. It is also possible 40238438Sdtesketo configure sendmail to achieve good performance in all cases, but 41260678Sdteskeit will not be optimal for any specific purpose. For example, it 42260678Sdteskeis non-trivial to combine low latency (fast delivery of incoming 43238438Sdteskemail) with high overall throughput. 44238438Sdteske 45238438SdteskeBefore we explore the different scenarios, a basic discussion about 46238438Sdteskedisk I/O, delivery modes, and queue control is required. 47238438Sdteske 48238438Sdteske 49238438Sdteske* Disk I/O 50238438Sdteske----------------------------------------------- 51238438Sdteske 52238438SdteskeIn general mail will be written to disk before a delivery attempt 53238438Sdteskeis made. This is required for reliability and should only be changed 54238438Sdteskein a few specific cases that are mentioned later on. To achieve 55238438Sdteskebetter disk I/O performance the queue directories can be spread 56238438Sdteskeover several disks to distribute the load. This is some basic tuning 57238438Sdteskethat should be done in all cases where the I/O speed of a single 58238438Sdteskedisk is exceeded, which is true for almost every high-volume 59251264Sdteskesituation except if a special disk subsystem with large (NV)RAM 60251361Sdteskebuffer is used. 61251361Sdteske 62251361SdteskeDepending on your OS there might be ways to speed up I/O, e.g., 63251361Sdteskeusing softupdates or turning on the noatime mount option. If this 64251361Sdteskeis done make sure the filesystem is still reliable, i.e., if fsync() 65251361Sdteskereturns without an error, the file has really been committed to 66251361Sdteskedisk. 67251361Sdteske 68251361Sdteske 69251361Sdteske* Queueing Strategies and DeliveryMode 70238438Sdteske----------------------------------------------- 71238438Sdteske 72251190SdteskeThere are basically three delivery modes: 73251190Sdteske 74251190Sdteskebackground: incoming mail will be immediately delivered by a new process 75251190Sdteskeinteractive: incoming mail will be immediately delivered by the same process 76251190Sdteskequeue: incoming mail will be queued and delivered by a queue runner later on 77251190Sdteske 78251361SdteskeThe first offers the lowest latency without the disadvantage of the 79238438Sdteskesecond, which keeps the connection from the sender open until the 80251236Sdteskedelivery to the next hop succeeded or failed. However, it does not 81251236Sdteskeallow for a good control over the number of delivery processes other 82249751Sdteskethan limiting the total number of direct children of the daemon 83238438Sdteskeprocesses (MaxChildren) or by load control options (RefuseLA, 84238438SdteskeDelayLA). Moreover, it can't make as good use as 'queue' mode can 85238438Sdteskefor connection caching. 86238438Sdteske 87251190SdteskeInteractive DeliveryMode should only be used in rare cases, e.g., 88251190Sdteskeif the delivery time to the next hop is a known quantity or if the 89251552Sdteskesender is under local control and it does not matter if it has to 90240768Sdteskewait for delivery. 91240768Sdteske 92240768SdteskeQueueing up e-mail before delivery is done by a queue runner allows 93251236Sdteskethe best load control but does not achieve as low latency as the 94251361Sdteskeother two modes. However, this mode is probably also best for 95256181Sdteskeconcurrent delivery since the number of queue runners can be specified 96251361Sdteskeon a queue group basis. Persistent queue runners (-qp) can be used 97251361Sdtesketo minimize the overhead for creating processes because they just 98251361Sdteskesleep for the specified interval (which should be short) instead of 99251361Sdteskeexiting after a queue run. 100251361Sdteske 101251361Sdteske 102240768Sdteske* Queue Groups 103238438Sdteske----------------------------------------------- 104238438Sdteske 105238438SdteskeIn most situations disk I/O is a bottleneck which can be mitigated 106238438Sdteskeby spreading the load over several disks. This can easily be achieved 107238438Sdteskewith different queue directories. sendmail 8.12 introduces queue 108238438Sdteskegroups which are collections of queue directories with similar 109238438Sdteskeproperties, i.e., number of processes to run the queues in the 110238438Sdteskegroup, maximum number of recipients within an e-mail (envelope), 111260678Sdteskeetc. Queue groups allow control over the behaviour of different 112251554Sdteskequeues. Depending on the setup, it is usually possible to have 113238438Sdteskeseveral queue runners delivering mails concurrently which should 114238438Sdteskeincrease throughput. The number of queue runners can be controlled 115238438Sdteskeper queue group (Runner=) and overall (MaxQueueChildren). 116238438Sdteske 117260678Sdteske 118260678Sdteske* DNS Lookups 119260678Sdteske----------------------------------------------- 120238438Sdteske 121238438Sdteskesendmail performs by default host name canonifications by using 122238438Sdteskehost name lookups. This process is meant to replace unqualified 123238438Sdteskehost name with qualified host names, and CNAMEs with the non-aliased 124238438Sdteskename. However, these lookups can take a while for large address 125238438Sdteskelists, e.g., mailing lists. If you can assure by other means that 126260678Sdteskehost names are canonical, you should use 127260678Sdteske 128260678Sdteske FEATURE(`nocanonify', `canonify_hosts') 129260678Sdteske 130260678Sdteskein your .mc file. For further information on this feature and 131260678Sdteskeadditional options see cf/README. If sendmail is invoked directly 132260678Sdtesketo send e-mail then either the -G option should be used or 133238438Sdteske 134238438Sdteske define(`confDIRECT_SUBMISSION_MODIFIERS', `C') 135238438Sdteske 136238438Sdteskeshould be added to the .mc file. 137238438Sdteske 138251554SdteskeNote: starting with 8.15, sendmail will not ignore temporary map 139238438Sdteskelookup failures during header rewriting, which means that DNS lookup 140238438Sdteskeproblems even for headers will cause messages to stay in the queue. 141238438SdteskeHence it is strongly suggested to use the nocanonify feature; 142238438Sdteskeat least turning it on for the MTA, but maybe disabling it for the 143238438SdteskeMSA, i.e., use Modifiers for DaemonPortOptions accordingly. 144238438SdteskeAs a last resort, it is possible to override the host map to ignore 145238438Sdtesketemporary failures, e.g., 146238438SdteskeKhost host -t 147238438SdteskeHowever, this can cause inconsistent header rewriting. 148238438Sdteske 149238438Sdteske 150238438Sdteske* Mailing Lists and Large Aliases (1-n Mailing) 151238438Sdteske----------------------------------------------- 152238438Sdteske 153238438SdteskeBefore 8.12 sendmail would deliver an e-mail sequentially to all its 154238438Sdteskerecipients. For mailing lists or large aliases the overall delivery 155238438Sdtesketime can be substantial, especially if some of the recipients are 156238438Sdteskelocated at hosts that are slow to accept e-mail. Some mailing list 157238438Sdteskesoftware therefore "split" up e-mails into smaller pieces with 158238438Sdteskefewer recipients. sendmail 8.12 can do this itself, either across 159238438Sdteskequeue groups or within a queue directory. The latter is controlled 160251554Sdteskeby the 'r=' field of a queue group declaration. 161251554Sdteske 162251554SdteskeLet's assume a simple example: a mailing list where most of the 163251554Sdteskerecipients are at three domains: the local one (local.domain) and 164260678Sdtesketwo remotes (one.domain, two.domain) and the rest is splittered 165251554Sdteskeover several other domains. For this case it is useful to specify 166238438Sdteskethree queue groups: 167238438Sdteske 168238438SdteskeQUEUE_GROUP(`local', `P=/var/spool/mqueue/local, F=f, R=2, I=1m')dnl 169238438SdteskeQUEUE_GROUP(`one', `P=/var/spool/mqueue/one, F=f, r=50, R=3')dnl 170238438SdteskeQUEUE_GROUP(`two', `P=/var/spool/mqueue/two, F=f, r=30, R=4')dnl 171238438SdteskeQUEUE_GROUP(`remote', `P=/var/spool/mqueue/remote, F=f, r=5, R=8, I=2m')dnl 172238438Sdteskedefine(`ESMTP_MAILER_QGRP', `remote')dnl 173238438Sdteskedefine(`confDELIVERY_MODE', `q')dnl 174238438Sdteskedefine(`confMAX_QUEUE_CHILDREN', `50')dnl 175238438Sdteskedefine(`confMIN_QUEUE_AGE', `27m')dnl 176238438Sdteske 177238438Sdteskeand specify the queuegroup ruleset as follows: 178250633Sdteske 179238438SdteskeLOCAL_RULESETS 180252178SdteskeSqueuegroup 181238438SdteskeR$* @ local.domain $# local 182238438SdteskeR$* @ $* one.domain $# one 183238438SdteskeR$* @ $* two.domain $# two 184238438SdteskeR$* @ $* $# remote 185238438SdteskeR$* $# mqueue 186238438Sdteske 187238438SdteskeNow it is necessary to control the number of queue runners, which 188238438Sdteskeis done by MaxQueueChildren. Starting the daemon with the option 189238438Sdteske-q5m assures that the first delivery attempt for each e-mail is 190238438Sdteskedone within 5 minutes, however, there are also individual queue 191238438Sdteskeintervals for the queue groups as specified above. MinQueueAge 192238438Sdteskeis set to 27 minutes to avoid that entries are run too often. 193238438Sdteske 194238438SdteskeNotice: if envelope splitting happens due to alias expansion, and 195251905SdteskeDeliveryMode is not 'i'nteractive, then only one envelope is sent 196251905Sdteskeimmediately. The rest (after splitting) are queued up and queue 197238438Sdteskerunners must come along and take care of them. Hence it is essential 198251905Sdteskethat the queue interval is very short. 199238438Sdteske 200251905Sdteske 201251905Sdteske* 1-1 Mass Mailing 202238438Sdteske----------------------------------------------- 203238438Sdteske 204238438SdteskeIn this case some program generates e-mails which are sent to 205238438Sdteskeindividual recipients (or at most very few per e-mail). A simple 206238438Sdteskeway to achieve high throughput is to set the delivery mode to 207238438Sdteske'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