后缀性能与 main.cf 中的列表

Question

要定义要分配给 postfix 中许多不同选项的项目列表，您可以使用逗号分隔列表，如下所示：

relay_domains = example.com,example.net,example.org

或者像这样的哈希映射：

relay_domains = hash:/etc/postfix/relay_domains

然后使用 postmap 将该键值项文件转换为 bdb 文件。

我的问题是：使用哈希映射而不是仅指定列表是否有任何性能原因？

Answer 1

我没有数据或指标来决定性能在这两种情况下是否重要。我将尝试解释涉及这两种情况的后台进程。

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

• 使用时main.cf，postfix 会解析配置文件，将其保存到内存中，并且在 postfix 重新启动或管理员发出postfix reload命令之前不会再次检查该文件。
• 使用哈希表时，postfix 会解析该表，将其保存到内存中并定期检查文件是否更改。如果数据库被更改，postfix 将在处理下一个客户端请求之前终止，以便新进程可以使用新数据库初始化。^来源

现在，如果您想更改列表，则

• 更改后main.cf，您应该调用postfix reload. 它将强制主守护进程重新读取配置文件并终止子进程，以便它可以获取新配置。^来源
• 更改哈希表后，无需调用postfix reload.

我仍然不明白（1）通过手动调用重新启动子进程postfix reload和（2）重新启动由哈希表触发的子进程之间的区别已被修改。

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

Postfix 有一个叫做master的主进程。它第一次调用并充当“主”程序。它按需调用其他守护进程，例如 smtpd、qmgr、trivial-rewrite。

有四种后缀守护进程

1. 不会死的守护进程，因此它不会自动获取对 main.cf 的更改。postfix reload在配置更改后调用将使进程重新读取它。这包括：master。
2. 守护进程成为持久进程，因此它不会自动获取对 main.cf 的更改。postfix reload在配置更改后调用将使进程重新读取它。这包括：qmgr、tlsmgr、verify。
3. 可以运行一小时或几个小时的长时间运行的过程。postfix reload在配置更改后调用将加快配置更改。这包括：trivial-rewrite、pickup、postscreen、proxymap
4. 只运行有限时间的短期运行进程。调用postfix reload是不必要的，因为进程再次运行时会重新读取 main.cf。这包括smtp、smtpd、local和除上述三类之外的其他进程。

如果您main.cf用于存储列表但未调用postfix reload，则

• 守护进程类别 4 将在进程恢复后立即拾取它，因为它的时间很短。
• 守护进程类别 3 需要一些时间才能获得效果
• 守护进程类别 1 和 2 永远不会重新读取，main.cf直到您调用postfix reload：

当您使用哈希表来存储列表并postmap-ed 文件时，然后

• 守护进程类别 2、3、4 将检测文件更改。所以不需要做postfix重新加载。
• 守护进程类别 1 没有散列类型的参数值。所以，它对主守护进程没有影响。

结论

否则，看起来上述两种情况之间的性能差异很小。如果你很少换表，那么差异可以忽略不计。例外是如果你经常做postfix reload或更改哈希表，那么它会在qmgr处理过程中出现性能问题。看到这里和这里

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