As each is added, each slows all the others that are already running,
and it isn??™t long before the load on the machine starts to climb and the rate at
which messages are delivered falls at an alarming rate. In fact, when this sort of
behavior hits a very large-volume site, a sendmail queue-processing daemon can start
and seem to never finish.
Depending on the speed of your disk system, even limiting the number of queue processors
per queue might not save you from this sluggish performance. Under V8.12
sendmail, for example, you can limit the number of queue runners per queue with a
queue group (?§11.4 on page 408) definition suchas this in your mc configuration
file:
QUEUE_GROUP(`fastq??, `P=/q/fastq*, I=10m, R=10??)
Here, the fastq group uses the queue disks mounted as /q/fastq*, processes those
disks once per 10 minutes (the I=10m), and limits itself to 10 queue runners maximum
(the R=10) across all the disks. If there are few fastq* queue disks, and if they
fill to more than 30,000 messages each, they too can become sluggish, even with only
10 runners processing them. In fact, with sufficient filled queue depth, as few as two
simultaneous queue runners can seriously affect performance.
In extreme situations suchas this, one alternative is to use persistent queue runners
(?§11.8.3 on page 434). Withpersistent queue runners, you maintain a single queue
runner that alone reads the queue.
Pages:
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732