MTA performance: CPU and resources

Not necessarily in order of importance, here are some points to consider:



 In versions past, it was important to use a compiled configuration, to reduce the startup time of MTA processing jobs. As of 7.0.5 and Unified Configuration, this is no longer important. 

 If your system has the memory to spare, increasing the size of message that processing jobs can buffer internally can reduce use of temporary buffer files on disk when receiving or processing large messages. See the discussion of the  MTA option. On an LMTP back end system, see instead the   TCP/IP-channel-specific option. 

 Ensure that you have sufficient swap space for the needs of your configuration. 

 Consider Job Controller pools for specific channels which you wish to ensure always have processing slots. The usual initial configuration establishes a basic set of pools suitable for the typical use of the channels in the initial configuration, but if you have added special purpose channels to your configuration, or if your site&#x27;s message traffic has special characteristics or you have special needs, then you may benefit from adding new pool definitions and/or assigning particular channels to different pools. For instance, if you have a dedicated, heavy-use TCP/IP channel for sending to some sister site, then you may wish to define a separate pool that will be dedicated for the use of that special channel. Then use the   channel option to direct the special channel to run in that new pool. 

 The Dispatcher controls the creation and use of multithreaded SMTP server processes. If, as is typical, incoming SMTP over TCP/IP messages are a major component of e-mail traffic at your site, monitor how many simultaneous incoming SMTP connections you tend to have, and the pacing at which such connections come in. Tuning of Dispatcher configuration options  controlling the number of SMTP server processes, the number of connections each can handle, the threshold at which new server processes are created, etc., may be beneficial if your site&#x27;s incoming SMTP over TCP/IP traffic is unusually high or low. 

 In general, for outgoing SMTP over TCP/IP channels, adjustment of the number of messages handled per thread (  channel option),  the maximum number of threads per process  (MAX_CLIENT_THREADS TCP/IP-channel-specific  option), the maximum number of processes for the channel  (  channel option, potentially also  limited by the Job Controller&#x27;s    option value for the    in which the channel runs), can  potentially be beneficial, especially if your site&#x27;s message traffic has out of the ordinary characteristics. For typical SMTP over TCP/IP channels, used to send to multiple different remote systems, the MTA&#x27;s multithreaded TCP/IP channel&#x27;s default behavior of sorting messages to different destinations into different threads and then handling all messages (up to the channel&#x27;s   channel option&#x27;s value) to a single host in a single thread is desirable for performance; indeed, in some cases increasing such a channel&#x27;s    may be useful. However, for a   TCP/IP channel, one dedicated to sending to a specific system, if the receiving system supports multiple simultaneous connections it may be preferable to force the MTA to split the outgoing messages into separate threads at a lower threshold, by using a "small"    value, and then perhaps correspondingly adjusting to allow more threads and/or more processes using the    TCP/IP-channel-specific option or the   channel option, respectively. And see also the discussion above regarding defining and using new pools for particular channels, to control the degree of resource sharing/resource competion among separate outgoing TCP/IP channels. 

 Disabling the MTA&#x27;s SMTP server creation and use of   files by setting the TCP/IP-channel-specific option     can provide a noticable performance (throughput) increase---perhaps 30% for the SMTP server; the downside is that disabling their use means that the MTA will no longer detect and avoid certain cases of duplicate submissions of messages, so users may receive "duplicate" copies of messages that might have been avoided. (The main performance issue here is not usually the creation of the actual files, but rather the CPU used while deciding whether to make such a file; that is, the performance impact of such potential file use exists whether or not any  file is in fact ever created.) 

 Another channel heavily used at typical sites is the   channel  for delivery to the Message Store. This, like the TCP/IP channels, is a multithreaded channel, and controls over its ,    -channel-specific option,   , and the    for the    in which it runs can potentially be relevant to performance, particularly if your site&#x27;s needs are out of the ordinary. </li>

 Use of LMTP back ends  allows separation of MTA systems from back end Message Store systems, so that individual systems may be dedicated to one type of functionality or the other. Configuration of MTA LMTP client channels can benefit both from the sorts of considerations for   channels (regarding Message Store delivery) and from the sorts of considerations for TCP/IP channels (regarding the network connectivity). Consider using a separate Job Controller   or  s for the LMTP client channel(s). When there are multiple back end LMTP systems, note that there are tradeoffs between using one channel to deliver to all back ends, vs. creating separate channels to deliver to each back end. </li>

 In direct LDAP mode, the caching of LDAP lookups represents a tradeoff between efficiency ("large" caches), vs. memory usage (which should not be too great a burden on a reasonably sized system) and small latency in LDAP entry changes ("small" caches). See especially the ,  ,  ,  ,  and    MTA options,  and to a lesser degree the    and    MTA options, which all fall into the category of LDAP lookup caching. Sites using Sieve filters should also see   and   ;  sites making heavy use of custom LDAP callouts (from mapping tables or rewrite  rules) should also see   and  , also in that same category of LDAP lookup caching. </li>

 When generating very large "mass mailings", see Performance submitting mass mail messages. </li>

 Note that increased processing or filtering of messages, such as that resulting from processing the inner levels of messages (,    channel options), "sniffing" of message bodies  (  or    channel options or    keywords), use of  character set conversion, use of the conversion channel, use of  Sieve filters, use of  callouts to third party virus or spam detection software such as Brightmail or Spamassassin, MIME message fragmentation or defragmentation  ( ,    channel options), use of TLS for encryption of SMTP messages  (  channel options), use of DNS reverse lookups for incoming SMTP messages  (  channel options,   channel options,   channel option,  or    image callouts from an   mapping table), etc., requires the MTA to do extra work hence of course has a performance impact. This is not to discourage use of such features---such features exist because they are useful, and desirable features for message processing---but do keep in mind the potential performance impact of increased message processing. </li>

 In particular, especially for system-wide or channel Sieve filters, it may be worth paying some attention to ensure that such Sieves use reasonable test logic, and are not really excessively long (excessively many tests). </li>

 Also, when using mapping tables, such as   mapping tables, it is worthwhile to set up the mapping tables in an efficient way, without excessive numbers of entries, and attempting to keep the pattern matching reasonably efficient. As a rough rule of thumb, consider that once a mapping table has reached about 50 entries (lines), it is worth considering whether the table could be restructured to make use of general database callouts to do some of the specific matching, rather than having all matching text explicitly present in the mapping table itself. </li>

 When callouts to third party spam/virus filter  packages  such as Brightmail or Spamassassin are part of the configuration, it is important to size and tune those third party filter packages adequately: their important filtering functionality tends to be inherently "expensive". </li>

</ul>

See also:
 * MTA performance tuning
 * Compiling the MTA configuration
 * max_internal_blocks MTA Option
 * pool Option
 * threaddepth Option
 * maxjobs Option
 * job_limit Option
 * daemon Option
 * LDAP lookup cache MTA options
 * inner Option
 * innertrim Option
 * thurman Option
 * uma Option
 * Character set conversion
 * Conversion channel
 * maxblocks Option
 * defragment Option
 * maytls Option
 * forwardcheckdelete Option
 * mailfromdnsverify Option
 * Recipient access mapping tables
 * Sieve filters
 * Handling large numbers of mapping table entries
 * Spam and virus filtering
 * Performance submitting mass mail messages