diff options
Diffstat (limited to 'contrib/sendmail/src/TUNING')
| -rw-r--r-- | contrib/sendmail/src/TUNING | 230 |
1 files changed, 0 insertions, 230 deletions
diff --git a/contrib/sendmail/src/TUNING b/contrib/sendmail/src/TUNING deleted file mode 100644 index fe9e6947af6a..000000000000 --- a/contrib/sendmail/src/TUNING +++ /dev/null @@ -1,230 +0,0 @@ -# Copyright (c) 2001-2003 Sendmail, Inc. and its suppliers. -# All rights reserved. -# -# By using this file, you agree to the terms and conditions set -# forth in the LICENSE file which can be found at the top level of -# the sendmail distribution. -# -# $Id: TUNING,v 1.21 2006/09/25 16:45:05 ca Exp $ -# - -******************************************** -** This is a DRAFT, comments are welcome! ** -******************************************** - - -If the default configuration of sendmail does not achieve the -required performance, there are several configuration options that -can be changed to accomplish higher performance. However, before -those options are changed it is necessary to understand why the -performance is not as good as desired. This may also involve hardware -and software (OS) configurations which are not extensively explored -in this document. We assume that your system is not limited by -network bandwidth because optimizing for this situation is beyond -the scope of this guide. In almost all other cases performance will -be limited by disk I/O. - - -This text assumes that all options which are mentioned here are -familiar to the reader, they are explained in the Sendmail Installation -and Operations Guide; doc/op/op.txt. - -There are basically three different scenarios which are treated -in the following: -* Mailing Lists and Large Aliases (1-n Mailing) -* 1-1 Mass Mailing -* High Volume Mail - -Depending on your requirements, these may need different options -to optimize sendmail for the particular purpose. It is also possible -to configure sendmail to achieve good performance in all cases, but -it will not be optimal for any specific purpose. For example, it -is non-trivial to combine low latency (fast delivery of incoming -mail) with high overall throughput. - -Before we explore the different scenarios, a basic discussion about -disk I/O, delivery modes, and queue control is required. - - -* Disk I/O ------------------------------------------------ - -In general mail will be written to disk before a delivery attempt -is made. This is required for reliability and should only be changed -in a few specific cases that are mentioned later on. To achieve -better disk I/O performance the queue directories can be spread -over several disks to distribute the load. This is some basic tuning -that should be done in all cases where the I/O speed of a single -disk is exceeded, which is true for almost every high-volume -situation except if a special disk subsystem with large (NV)RAM -buffer is used. - -Depending on your OS there might be ways to speed up I/O, e.g., -using softupdates or turning on the noatime mount option. If this -is done make sure the filesystem is still reliable, i.e., if fsync() -returns without an error, the file has really been committed to -disk. - - -* Queueing Strategies and DeliveryMode ------------------------------------------------ - -There are basically three delivery modes: - -background: incoming mail will be immediately delivered by a new process -interactive: incoming mail will be immediately delivered by the same process -queue: incoming mail will be queued and delivered by a queue runner later on - -The first offers the lowest latency without the disadvantage of the -second, which keeps the connection from the sender open until the -delivery to the next hop succeeded or failed. However, it does not -allow for a good control over the number of delivery processes other -than limiting the total number of direct children of the daemon -processes (MaxChildren) or by load control options (RefuseLA, -DelayLA). Moreover, it can't make as good use as 'queue' mode can -for connection caching. - -Interactive DeliveryMode should only be used in rare cases, e.g., -if the delivery time to the next hop is a known quantity or if the -sender is under local control and it does not matter if it has to -wait for delivery. - -Queueing up e-mail before delivery is done by a queue runner allows -the best load control but does not achieve as low latency as the -other two modes. However, this mode is probably also best for -concurrent delivery since the number of queue runners can be specified -on a queue group basis. Persistent queue runners (-qp) can be used -to minimize the overhead for creating processes because they just -sleep for the specified interval (which should be short) instead of -exiting after a queue run. - - -* Queue Groups ------------------------------------------------ - -In most situations disk I/O is a bottleneck which can be mitigated -by spreading the load over several disks. This can easily be achieved -with different queue directories. sendmail 8.12 introduces queue -groups which are collections of queue directories with similar -properties, i.e., number of processes to run the queues in the -group, maximum number of recipients within an e-mail (envelope), -etc. Queue groups allow control over the behaviour of different -queues. Depending on the setup, it is usually possible to have -several queue runners delivering mails concurrently which should -increase throughput. The number of queue runners can be controlled -per queue group (Runner=) and overall (MaxQueueChildren). - - -* DNS Lookups ------------------------------------------------ - -sendmail performs by default host name canonifications by using -host name lookups. This process is meant to replace unqualified -host name with qualified host names, and CNAMEs with the non-aliased -name. However, these lookups can take a while for large address -lists, e.g., mailing lists. If you can assure by other means that -host names are canonical, you should use - - FEATURE(`nocanonify', `canonify_hosts') - -in your .mc file. For further information on this feature and -additional options see cf/README. If sendmail is invoked directly -to send e-mail then either the -G option should be used or - - define(`confDIRECT_SUBMISSION_MODIFIERS', `C') - -should be added to the .mc file. - - -* Mailing Lists and Large Aliases (1-n Mailing) ------------------------------------------------ - -Before 8.12 sendmail would deliver an e-mail sequentially to all its -recipients. For mailing lists or large aliases the overall delivery -time can be substantial, especially if some of the recipients are -located at hosts that are slow to accept e-mail. Some mailing list -software therefore "split" up e-mails into smaller pieces with -fewer recipients. sendmail 8.12 can do this itself, either across -queue groups or within a queue directory. The latter is controlled -by the 'r=' field of a queue group declaration. - -Let's assume a simple example: a mailing list where most of the -recipients are at three domains: the local one (local.domain) and -two remotes (one.domain, two.domain) and the rest is splittered -over several other domains. For this case it is useful to specify -three queue groups: - -QUEUE_GROUP(`local', `P=/var/spool/mqueue/local, F=f, R=2, I=1m')dnl -QUEUE_GROUP(`one', `P=/var/spool/mqueue/one, F=f, r=50, R=3')dnl -QUEUE_GROUP(`two', `P=/var/spool/mqueue/two, F=f, r=30, R=4')dnl -QUEUE_GROUP(`remote', `P=/var/spool/mqueue/remote, F=f, r=5, R=8, I=2m')dnl -define(`ESMTP_MAILER_QGRP', `remote')dnl -define(`confDELIVERY_MODE', `q')dnl -define(`confMAX_QUEUE_CHILDREN', `50')dnl -define(`confMIN_QUEUE_AGE', `27m')dnl - -and specify the queuegroup ruleset as follows: - -LOCAL_RULESETS -Squeuegroup -R$* @ local.domain $# local -R$* @ $* one.domain $# one -R$* @ $* two.domain $# two -R$* @ $* $# remote -R$* $# mqueue - -Now it is necessary to control the number of queue runners, which -is done by MaxQueueChildren. Starting the daemon with the option --q5m assures that the first delivery attempt for each e-mail is -done within 5 minutes, however, there are also individual queue -intervals for the queue groups as specified above. MinQueueAge -is set to 27 minutes to avoid that entries are run too often. - -Notice: if envelope splitting happens due to alias expansion, and -DeliveryMode is not 'i'nteractive, then only one envelope is sent -immediately. The rest (after splitting) are queued up and queue -runners must come along and take care of them. Hence it is essential -that the queue interval is very short. - - -* 1-1 Mass Mailing ------------------------------------------------ - -In this case some program generates e-mails which are sent to -individual recipients (or at most very few per e-mail). A simple -way to achieve high throughput is to set the delivery mode to -'interactive', turn off the SuperSafe option and make sure that the -program that generates the mails can deal with mail losses if the -server loses power. In no other case should SuperSafe be set to -'false'. If these conditions are met, sendmail does not need to -commit mails to disk but can buffer them in memory which will greatly -enhance performance, especially compared to normal disk subsystems, e.g., -non solid-state disks. - - -* High Volume Mail ------------------------------------------------ - -For high volume mail it is necessary to be able to control the load -on the system. Therefore the 'queue' delivery mode should be used, -and all options related to number of processes and the load should -be set to reasonable values. It is important not to accept mail -faster than it can be delivered; otherwise the system will be -overwhelmed. Hence RefuseLA should be lower than QueueLA, the number -of daemon children should probably be lower than the number of queue -runners (MaxChildren vs. MaxQueueChildren). DelayLA is a new option -in 8.12 which allows delaying connections instead of rejecting them. -This may result in a smoother load distribution depending on how -the mails are submitted to sendmail. - - -* Miscellaneous ------------------------------------------------ - -Other options that are interesting to tweak performance are -(in no particular order): - -SuperSafe: if interactive DeliveryMode is used, then this can -be set to the new value "interactive" in 8.12 to save some disk -synchronizations which are not really necessary in that mode. - |