All the mail it tries to send that hour fails, and instead of being removed from
the queue, this failed mail is left there to be tried again later (presumably after the
problem is fixed).
An hour later, service is restored. First, the default:
/usr/sbin/sendmail -q10m
causes a forked copy of sendmail to start processing the queue. This time, however,
the processing is not swift. When a queue fills to 30,000 or more messages, the
amount of time it takes to preread the queue (to open and read every message)
increases to more than 20 minutes.* And those 20 minutes are only for the preread.
During those 20 minutes no mail will be sent.
After that, things get worse. Ten minutes later a second sendmail daemon is forked,
and it, too, starts to preread the queue. Now, instead of one sendmail daemon opening
and reading all messages in a queue, we have two sendmail daemons doing the
same thing in parallel.
Contrary to what you might think, twice as much I/O on a disk is not twice as fast.
Disks are finite devices that perform a limited number of disk-head moves?? per second
and can transmit only a fixed number of bytes per second. Because the two sendmail
daemons are 10 minutes out of step witheachoth er, eachis reading and
* Again, for simplicity, we assume a standard hard disk. Naturally, reads will be much faster on specialty hardware
such as memory-based disks.
Pages:
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730