|
6.4 Buffered File I/OFor safety sake, and to ensure that no email messages are ever lost, sendmail queues all messages prior to the first delivery attempt. The SuperSafe option (SuperSafe) controls this behavior. When sending huge amounts of mail to lists of subscriber recipients, however, the safety of any single message can be less important than the overall speed of delivery. Although we do not recommend turning off the SuperSafe option, you can do so when you can tolerate the loss of messages should a mail-sending machine crash: define(`confSAFE_QUEUE',`False') The SuperSafe option causes every message not only to be queued, but also to be flushed to that queue and the file synced to disk. In a situation where most email is delivered on the first try, a benefit derived from turning off SuperSafe is that most messages will never be saved to disk. They will instead be delivered out of the disk cache in memory, greatly increasing throughput. Note that, at sites that mix subscription and internal email, simply turning off the SuperSafe option might not be the best solution. While it might be acceptable to lose subscription mail, losing internal company email probably isn't. An alternative to queueing or not queueing everything is to use buffered file I/O to queue portions of messages or messages over a certain size. Buffered I/O was introduced in V8.10 sendmail but was usable only with BSD-derived flavors of Unix. Beginning with V8.12 sendmail, buffered I/O is available for all flavors of Unix. Buffered I/O is sendmail's ability to hold information in memory until it is required on disk, until it reaches some maximum size, or until the message is delivered. Whenever a message is queued to disk, it is saved in two parts. The qf part is a file that contains all the controlling information about the message, as well as all the headers for the message. The df is a file that contains the message body. In addition, whenever a message is being processed for delivery, a record of all replies generated by attempting to send it are saved in a third file called an xf file. Clearly, when file I/O is of concern, you will benefit by preventing file I/O whenever possible. One way to do this is to use the DataFileBufferSize option (DataFileBufferSize) to prevent the automatic creation of small df files. Another method is to use the XscriptFileBufferSize option (XscriptFileBufferSize) to prevent the automatic creation of tiny xf files. Note that the qf file is kept in memory as long as possible before being written to disk (more about this later). Beginning with V8.10 sendmail, these two options were available only if you could define the confSTDIOTYPE build macro (confSTDIOTYPE) to torek when building sendmail. Beginning with V8.12 sendmail, these two options are available for all versions of Unix, and confSTDIOTYPE does not need to be declared: define(`confDF_BUFFER_SIZE', `4000') define(`confXF_BUFFER_SIZE', `2000') The first line of abstract from an mc configuration file declares a size for the DataFileBufferSize option. This declaration tells sendmail that any df file for a given message should be held in memory and not written to disk until its size grows larger than 4,000 bytes. The presumption here is that mailing-list messages will always be smaller than 4,000 bytes, so they should not be written to disk. Company mail, because attachments are common, is often more than 4,000 bytes and so is commonly queued. The second line declares a size for the XscriptFileBufferSize option. Whenever sendmail attempts to deliver an email message, it always creates an xf file that corresponds to the qf and df parts for the message. The xf file contains a transcript of replies and input from the delivery agent. When a message is bounced, the last line of that file is printed as the reason for the bounce. Clearly, because most mail succeeds, creation of xf files (most of which are never larger than zero bytes) imposes unnecessary hardship on a possibly already overloaded disk. By setting the XscriptFileBufferSize option's value to 2,000 bytes, we prevent xf file creation on disk except for those rare occasions when the transcript of an error in delivery is longer than 2,000 bytes. Defining these two options eliminates the creation and removal of two of the three files that make up all email messages. On average, this should triple the number of messages that can be handled by any given queue disk, provided there are few bounces, and few huge (more than 4K) message bodies. The qf file can also be prevented from being written to disk. All you need to do is set the following two options as shown: define(`confSAFE_QUEUE',`interactive') define(`confDELIVERY_MODE',`i') If you set the delivery mode to interactive, as shown, we recommend you feed messages to sendmail sorted in host-order. Because sendmail caches connections (keeps them temporarily open to already delivered-to hosts), it is faster to deliver more messages to those still-connected hosts than to break down a connection and then to connect to a new host. Also, interactive delivery mode prevents sendmail from forking to deliver each message. By combining these properties, very swift delivery can be achieved. To sort messages in host-order, simply reverse the domain parts of the address. First, discard and save the user part (the part before the @), then reverse the pieces of the domain part (the pieces following the @), as shown here: trainer@leo.lion.com reverses to Then, sort this reversed list, reverse again, and restore the saved user parts: com.lion reverse again to A sort such as this will group domains and subdomains together. For example, lion.com and leo.lion.com will be grouped together. This is advantageous because they probably have a common MX record, and so delivery for them will be to a common host. On the downside, you should not use interactive mode unless you are feeding sendmail a large number of messages in sorted order. This mode prevents the normal fork for delivery, and will adversely impact performance on a normal mail-handling machine.  |
all versions, see later
com.lion.leo
betty@fred.edu reverses to|
|