MTA performance: Disks and files

One of the more common bottlenecks for the MTA itself is disk I/O -- especially if the MTA is using the same disks or disk controller as the Message Store, which does a lot of disk I/O! The MTA itself does a lot of disk I/O. Try to keep the disks with the MTA&#x27;s message queues below 66% capacity so that the operating system can efficiently manage file create and delete cycles. Also, use disk striping or other aggregate disk spindle techniques that help both read and writes. Avoid disk shadowing if possible. Disk is cheap these days: spend money on multiple spindles and sufficient free space.

By using symbolic links under the MTA&#x27;s queue and  log directories, you can  redirect where the MTA keeps its store-and-forward message queues and  log files. The MTA&#x27;s command, executable, and  configuration directories   can also  be separated if absolutely necessary.

Note that MTA debugging, which can be enabled for various components, and at various levels, (see for instance, the  and   options for the Dispatcher and Job Controller, respectively, and the   and   channel options for channels) is in some cases potentially very verbose and voluminous. MTA debugging is distinct from MTA transaction logging (which is, however, also written to the MTA log directory). Debugging is intended for short-term use to track down problems. Leaving debugging enabled unnecessarily for extended periods may make the MTA log directory "hotter" than desirable for the long term.

The location for MTA temporary files can also be moved. The  MTA option  (formerly   in the MTA Tailor file) controls the location of temporary unnamed files (such as those used to  buffer incoming large SMTP messages or incoming  large messages  submitted by local users, and to buffer all incoming LMTP  messages); it also controls the location of temporary named files (such  as those used by the conversion channel). defaults to ; note than on Linux, it tends to be preferable to set it explicitly to. Note that if explicitly defining   (and intending to support message  submissions directly from command line utilities by users  logged onto  the MTA system itself) it is important to point it to a device on which  any user may create files.

By default, the messages for a given channel are stored in a single, channel-specific directory under   the MTA queue directory,  . File system performance degrades rapidly for directories with more than a couple  thousand files; this can present a problem for channels which see heavy  message traffic --- especially when the network associated with that  channel is down and messages begin to queue up. Use the   channel option to indicate that a channel should  uniformly spread its messages across several subdirectories. For Internet sites with heavy traffic loads, this should be done for their  outgoing TCP/IP channel, usually.

MTA options such as   and    may affect file system I/O  performance and hence impact MTA performance.

UNIX sites may consider whether for their use it is acceptable to set the MTA option. Doing so improves performance, but at the cost that if a UNIX (or NT) system crashes at just the wrong moment,  messages not yet synched to disk could be lost.

Sites running on Solaris, and especially on Solaris 10 (which has a high default   value), if running a version of  the MTA prior to MS 6.4, should take steps to check and ensure that  a high system maximum file descriptor limit is not unduly burdening the  Job Controller and the channel delivery jobs that it initiates; see  System parameters on Solaris.

See also:
 * imta_queue MTA Option
 * imta_log MTA Option
 * imta_lib MTA Option
 * imta_bin MTA Option
 * imta_table MTA Option
 * tmpdir Option
 * max_internal_blocks MTA Option
 * Conversion channel
 * subdirs Option
 * Typical TCPIP channels and servers
 * osync MTA Option
 * buffer_size MTA Option
 * fsync MTA Option
 * System parameters on Solaris
 * MTA performance tuning