在main.cf中列出后缀的性能

在这两种情况下，我没有数据或指标来决定性能是否重要。 我会试着解释涉及这两种情况的背景过程。

当postfix守护进程运行时，这两者之间几乎没有什么区别，因为：

• 当使用main.cf ，postfixparsingconfiguration文件，将其保存到内存中，直到postfix重新启动或pipe理员发出postfix reload命令后才再次检查文件。
• 当使用散列表时，postfixparsing表，将其保存到内存中并定期检查文件是否更改。 如果更改了数据库，postfix将在处理下一个客户端请求之前终止，以便新的进程可以使用新的数据库进行初始化。 ^资源

现在，如果你想改变列表，那么

• 更改main.cf ，您应该调用postfix reload 。 它将强制主守护程序重新读取configuration文件并终止subprocess，以便它可以拾取新的configuration。 ^资源
• 更改哈希表后，不需要调用postfix reload 。

但我不明白（1）通过手动调用postfix reload重新启动subprocess和（2）重新启动由哈希表触发的subprocess已被修改之间的差异。

这里有一些知识，阅读后缀手册页 ，特别是守护进程部分。 这有助于我理解（1）通过手动调用postfix reload重启subprocess和（2）重启哈希表触发的subprocess已被修改的区别。

Postfix拥有称为master的主进程。 它第一次援引，并作为“主”scheme。 它调用其他守护进程，如smtpd，qmgr，按需重写。

有四种types的后缀守护进程

1. 守护进程谁不会死，所以它不会自动接受对main.cf的更改。 在configuration更改后调用postfix reload将使进程重新读取它。 这包括： 主人 。
2. 守护进程成为持久进程，因此不会自动接受对main.cf的更改。 在configuration更改后调用postfix reload将使进程重新读取它。 这包括： qmgr ， tlsmgr ， validation 。
3. 长时间运行的程序可以运行一个小时或几个小时的范围。 在configuration更改后调用postfix reload会加速configuration更改。 这包括： 平凡重写 ， 皮卡 ， postscreen ， 代理地图
4. 运行时间短的stream程，只运行有限的时间。 调用postfix reload是不必要的，因为当再次运行时，进程会重新读取main.cf。 这包括smtp ， smtpd ， 本地和其他进程旁边的三个分类上面。

如果使用main.cf存储列表，但不调用postfix reload ，那么

• 守护者类别4会因为短暂的时间而在处理复活后立即取回。
• 守护程序类别3需要一些时间来获得效果
• 守护程序类别1和2永远不会重新读取main.cf直到您调用postfix reload ：

当你使用散列表来存储列表，然后你后贴图的文件

• 守护程序类别2,3,4将检测文件更改。 所以不需要做后缀重载。
• 守护程序类别1不具有散列types参数值。 所以，守护进程没有效果​​。

结论

否则，看起来上面两种情况之间的performance差异很小。 如果你很less改变表格，那么差别可以忽略不计。 例外的情况是，如果您经常执行postfix reload或更改哈希表，那么在qmgr进程中将会是性能问题。 看到这里和这里

更多信息： Postfix性能自述文件