Recipe 9.5 Using Persistent Queue Runners

Problem

Queues can become so large that queue runners interfere with each other.

Solution

In the system startup files, locate the command that starts sendmail with the -bd flag. Look for a line that is something like the following:

 /usr/sbin/sendmail -bd -q15m 

Change the -q argument to a -qp argument. For example:

 /usr/sbin/sendmail -bd -qp 

Terminate the currently running sendmail daemon queue processor:

 #  kill -TERM `head -1 /var/run/sendmail.pid`  

Start a new daemon process using the new command-line arguments:

 #  /usr/sbin/sendmail -bd -qp  

Discussion

The first step in this recipe modifies the startup script so that sendmail starts with the correct command-line arguments every time the system reboots. On some systems, finding and changing the line that starts sendmail at boot time is simple; on some other systems it is more complicated. Different Unix versions use different techniques to start sendmail at boot time, but all have some technique.

Most versions of Unix use a command similar to the following one to start the sendmail daemon:

 /usr/sbin/sendmail -bd -q15m 

This line contains two options: -bd and -q . Use -bd to accept inbound mail. The -bd argument causes sendmail to listen for inbound mail on the configured TCP ports, which, by default, are ports 25 and 587. Without a daemon running with -bd set, a properly configured system can still send outbound mail, but it will not collect inbound mail. [2] The -q option causes the daemon to periodically start queue processors. In this particular example, the daemon is told to start queue processors every 15 minutes ( 15m ).

[2] Recipe 10.1 configures sendmail to send outbound mail without running a daemon with the -bd option.

This recipe changes the -q flag to -qp . Changing the -q flag to -qp runs this daemon as a persistent queue processor. The difference between forking a queue runner every 15 minutes with -q15m and requesting a persistent queue runner with -qp is significant. In the first case, a new queue runner is launched every 15 minutes without regard to the status of the previous queue run. In the second case, a new queue runner is launched one second after the previous queue run completes. One second is the default interval timer for the -qp option. It can be changed on the command line by defining a different interval value; for example, sendmail -qp15s would set the interval to 15 seconds. However, one second is a good value. It provides essentially continuous queue processing without any interference between queue runners because the interval timer for the next queue runner doesn't start until the current queue run finishes.

At the start of every queue run, the queue runner reads all of the qf files, extracts certain control information, sorts it, and uses it to control the order in which queued messages are delivered. A persistent queue runner can be beneficial when an individual queue is so large that this first step takes longer than the selected queue interval. For example, using -q15m sets the queue interval to 15 minutes. If the initial step took 30 minutes, sendmail would start another queue runner at the 15-minute point and a third at the 30-minute point. Each runner would repeat the initial step only to be succeeded by additional runners doing the same job. Unfortunately, additional queue runners do not always speed up this first step. In fact, they sometimes interfere with each other so much that they slow things down. Using persistent queue runners avoids this problem.

When a persistent queue runner is used, it is allowed to finish its job without the interference of other queue runners. The persistent queue runner finishes the first step, forks multiple processes to deliver the mail it has sorted, and sleeps the queue interval before awaking to do it again. Because the queue interval does not start until after the persistent queue runner has finished the sort , no other queue runners are started while it is running. This completely avoids the problems associated with multiple runners sorting the same queue.

In addition to modifying the boot script, Recipe 9.5.2 closes out the current sendmail process with a SIGTERM and reruns sendmail from the command line using the new options. After restarting sendmail, a cat of the sendmail.pid file would show the command line /usr/sbin/sendmail -bd -qp . Subsequent restarts of the daemon can be done with the HUP signal because HUP uses the command found in sendmail.pid to restart sendmail.

Emergency queue clearance

Because this recipe permanently changes the system's default configuration, it is intended for systems where processing a very large queue is a chronic system problem. Manually running sendmail with settings that skip the time-consuming initial step is an alternative solution that can be used when the queue grows extremely large because of some unusual circumstance. In that case, kill all of the currently running sendmail processes and then enter the following command:

 #  /usr/sbin/sendmail -OQueueSortOrder=filename -q15m  

This QueueSortOrder option tells sendmail to deliver the mail in filename order. Alternatives are to deliver the queued mail in random order by using -OQueueSortOrder=random or in order of modification time from the oldest to the newest by using -OQueueSortOrder=modtime . In all of these cases, the qf files are not opened and read. Therefore the delivery order is not optimized. However, an enormous amount of time is saved at the start of the queue process, which is just what is needed to clear out an overstuffed queue. Once the queue is clear, kill this special copy of sendmail and restart the normal configuration.

Use Recipe 9.5 when chronic system performance problems are routinely caused by the overhead of processing very large mail queues. Use the QueueSortOrder option as a quick fix for an unusual queue processing problem.

See Also

The sendmail book describes persistent queue runners in Section 6.1 and the QueueSortOrder option in Section 6.1.1. The sendmail book provides interesting statistics about the queue processing time based on queue size and on the performance gains using these alternate solutions. Chapter 3 of sendmail Performance Tuning , by Nick Christenson (Addison Wesley), covers queue contention and recommends solutions for this problem.



Sendmail Cookbook
sendmail Cookbook
ISBN: 0596004710
EAN: 2147483647
Year: 2005
Pages: 178
Authors: Craig Hunt

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net