TUNING revision 168515
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.21 2006/09/25 16:45:05 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 138 139* Mailing Lists and Large Aliases (1-n Mailing) 140----------------------------------------------- 141 142Before 8.12 sendmail would deliver 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 list where most of the 152recipients are at three domains: the local one (local.domain) and 153two 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 215runners (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