main.cf のリストでの postfix のパフォーマンス

Question

両方のケースでパフォーマンスが重要かどうかを判断するためのデータや測定基準はありません。これら 2 つのケースに関係するバックグラウンドプロセスについて説明します。

postfix デーモンが実行されていた場合、次の理由によりこれら 2 つの間にほとんど違いはありません。

を使用するとmain.cf、postfix は設定ファイルを解析し、それをメモリに保存し、postfix が再起動されるか管理者がコマンドを発行するまでファイルを再度チェックしませんpostfix reload。
ハッシュテーブルを使用する場合、postfix はテーブルを解析し、それをメモリに保存し、ファイルが変更されたかどうかを定期的にチェックします。データベースが変更された場合、postfix は次のクライアント要求を処理する前に終了し、新しいプロセスが新しいデータベースで初期化できるようにします。^ソース

さて、リストを変更したい場合は、

を変更した後main.cf、を呼び出す必要がありますpostfix reload。これにより、マスターデーモンが構成ファイルを再度読み取り、子プロセスを終了して、新しい構成を取得できるようになります。^ソース
ハッシュテーブルを変更した後は、を呼び出す必要はありませんpostfix reload。

postfix reloadまだ、(1) 手動で呼び出して子プロセスを再起動することと、(2) ハッシュテーブルが変更されたことでトリガーされた子プロセスを再起動することの違いがわかりません。

読んだ後に知っておくべき知識postfix マニュアルページ特にデーモンプロセスpostfix reloadセクション。これにより、(1) 手動で呼び出して子プロセスを再起動することと、(2) ハッシュテーブルによってトリガーされて子プロセスを再起動することの違いを理解するのに役立ちます。

Postfixにはマスタープロセスと呼ばれるプロセスがありますマスター初めて呼び出され、「マスター」プログラムとして機能します。必要に応じて、smtpd、qmgr、trivial-rewrite などの他のデーモンを呼び出します。

postfixデーモンには4種類あります

終了しないデーモンなので、main.cf への変更を自動的に取得しません。postfix reload構成変更後に呼び出すと、プロセスはそれを再読み込みします。これには以下が含まれます:マスター。
永続プロセスになったデーモンは、main.cf への変更を自動的に取得しません。postfix reload構成変更後に呼び出すと、プロセスはそれを再読み込みします。これには以下が含まれます:管理者、TLS管理、確認する。
1 時間から数時間の範囲で実行できる長時間実行プロセス。postfix reload構成変更後に呼び出すと、構成変更が高速化されます。これには以下が含まれます。簡単な書き換え、選び出す、ポストスクリーン、プロキシマップ
限られた時間だけ実行される短時間実行プロセス。postfix reloadプロセスは再度実行するときにmain.cfを再度読み込むため、呼び出しは不要です。これには以下が含まれます。SMTP、SMTPD、地元上記の 3 つの分類以外のプロセス。

main.cfリストを保存するためにを使用しているがを呼び出さない場合はpostfix reload、

デーモンカテゴリ 4 は、その寿命が短いため、プロセスの復活後すぐにそれを拾い上げます。
デーモンカテゴリー3は効果が出るまでに時間がかかる
main.cfデーモンカテゴリ 1 および 2 は、以下を呼び出すまで再読み取りを行いませんpostfix reload。

リストを保存するためにハッシュテーブルを使用していて、postmapファイルを -ed した場合、

デーモンカテゴリ 2、3、4 はファイルの変更を検出します。したがって、postfix の再ロードを行う必要はありません。
デーモンカテゴリ 1 にはハッシュ型パラメータ値がないため、マスターデーモンには影響しません。

結論

それ以外の場合、上記の 2 つのケースのパフォーマンスの違いは小さいようです。テーブルをめったに変更しない場合は、違いは無視できます。例外として、postfix reloadハッシュテーブルを頻繁に実行または変更する場合は、プロセスのパフォーマンスが問題になりますqmgr。ここそしてここ

さらに詳しい情報:Postfix パフォーマンスの Readme

Answer 1