我注意到了这本手册中的以下内容：
刷新完整队列的最好方法是使用如下命令行：
/usr/sbin/sendmail -OQueueSortOrder=filename -q10m -d99.100
/usr/sbin/sendmail -OQueueSortOrder=random -q10m -d99.100←V8.12及更高版本/usr/sbin/sendmail -OQueueSortOrder=none -q10m -d99.100←V8.13及更高版本
- 如果RefuseLA和QueueLA具有相同的值，那么期望的sendmail行为是什么？
- 如何让sendmail将大量电子邮件发送到单个文件中的单个智能主机目标。
- 如果sendmail无法parsing智能主机，添加到队列，而不是失败？
- Sendmail：将virtuser帐户redirect到外部电子邮件地址
- Sendmail smrsh在Ubuntu / Debian上别名脚本pipe道问题
在这里，-d99.100告诉sendmail在前台运行（这样你就可以在完成时简单地杀死它）。 -q10m使队列处理守护进程每10分钟启动一次（就像以前一样）。 您需要这样做，因为一个守护进程在将邮件传递给慢速主机时可能会挂起。 通过运行并行守护进程，避免了这个陷阱。
后来在同一章中，它谈到设置间隔是一个坏主意：
一小时后，服务恢复。 一，默认：
/usr/sbin/sendmail -q10m会导致/usr/sbin/sendmail -q10m的分叉副本开始处理队列。 但这一次，处理并不快。 当一个队列填充到30,000或更多的消息时，预读队列（打开并读取每条消息）花费的时间增加到超过20分钟。 而这20分钟只是预读。 在这20分钟内，不会有邮件发送。之后，情况变得更糟。 十分钟后，第二个sendmail守护程序被分叉，并且它也开始预读队列。 现在，我们有两个sendmail守护进程并行执行相同的事情，而不是一个sendmail守护进程打开并读取队列中的所有消息。
与您可能认为的相反，磁盘上I / O的两倍不会快一倍。 磁盘是有限的设备，每秒执行有限数量的磁头移动[181]，每秒只能传输固定数量的字节。 因为两个sendmail守护进程彼此不同步，每个都在读取和处理单独的文件。 根据内存磁盘高速caching的大小，也不可能利用这种高速caching的效率。 简而言之，并行处理深队列的两个sendmail守护进程比单独处理同一队列的单个sendmail守护进程更糟糕。
如果这还不够，10分钟后第三个sendmail守护进程开始处理队列。
到目前为止，第一个sendmail守护进程可能已经完成了队列的预读，并可能实际上已经开始发送消息。 但即使有，三个sendmail守护进程正在处理这个单一的深度队列，并且发生了一件奇怪的事情。 因为持有队列的磁盘是有限的，添加第三个sendmail守护进程会减慢前两个操作。 第二个，而不是花20分钟预读队列，现在将需要30分钟。
这意味着每隔10分钟，另一个sendmail队列处理守护进程将被添加到混合中。 每添加一个，每个都会减慢已经运行的所有其他数据，并且在机器的负载开始攀升之前不久，传递消息的速率就会以惊人的速度下降。 实际上，当这种行为碰到一个非常大的站点时，sendmail队列处理守护进程就可以启动，似乎永远不会结束。
所以我觉得我正在阅读文档中的两个完全不同的东西：
什么是适合大队列的适当的行动？
你所看到的典型的是“只修一个问题，忽略其他可能的问题” – 这是几十年来“我为解决我的问题作出贡献”的发展所造成的。
第一个build议是处理相当大（但不是很大）的队列中的“缓慢处理”项目。
第二个build议处理巨大的队列处理，这使得默认的sendmail队列运行设置非常慢并且内存很大。
第一个build议可以通过使用改进
* MinQueueAge – 特定消息投递尝试之间的时间。
* MaxQueueRunSize – 队列运行器处理的最大消息数。
旧的RFCbuild议在发送尝试之间延迟30m。 其他MTA可以使用基于排队时间花费的投递尝试之间的不同延迟。
顺便说一下，MSA队列和主队列的处理应该单独进行优化。
恕我直言： 大多数非大网站可以手动处理巨大的队列。 由于黑客/漏洞，垃圾邮件运行频率最高的是“每几年一次”。 优化sendmail发送速度是没有意义的。 请参阅MSA队列报告中的18GB 。