私は、自分で書いたメール システムの最終配信に postfix を使用しています。そのため、この postfix インストールは私からのメールのみを受け入れ、バウンスします。postfix キューが空の場合、メールを 5 ミリ秒程度で受け入れることができます。キューに 150,000 ～ 200,000 件のメッセージがある場合、私から postfix へのハンドオフ速度は非常に遅く、50 ～ 100 ミリ秒、時には 500 ミリ秒になります。
SMTP 会話の各部分にログ時間があるので、どこに時間がかかっているかがわかります。そのうちの一部は RCPT TO コマンドからの応答を待っている間ですが、ほとんどの時間は最後のドットを送信した後、「250 OK キューに入れられました...」という応答を受け取る前に消えます。
RCPT TO 遅延は DNS ルックアップにあるのではないかと考えていますが、キューイング時間の問題には役立ちません。送信するすべての電子メールに対して 1 つの TCP ソケットを開いたままにしておき、各メールの会話を RSET します。そのため、TCP 接続の作成と切断に時間が無駄になることはありません。すべては postfix がメッセージをキューイングするのを待つだけです。
私がこれまで読んだ postfix のパフォーマンス チューニングに関する内容はすべて、キュー管理と、さまざまなドメインへのメール送信に関するものでした。しかし、私が関心を持っているのは、そもそも postfix がメールをすばやく受信できるようにすることです。
postfix がこの時間で何をしているのかを知る方法や、処理を高速化する方法はありますか? /var/spool/postfix キューはローカル ディスク上にあるため、これ以上高速化することはできません。
助言がありますか？
答え1
以下を設定main.cf
hash_queue_depth = 3
hash_queue_names = deferred, defer, incoming, active
これにより、受信キューとアクティブ キューにサブディレクトリが作成され、フラット ディレクトリにすべてのメールが一度に格納されなくなります。メールはサブディレクトリに格納されるようになりました。
ただし、注意: 15 万～ 20 万件のメッセージが配信待ちになっているということは、メールのバランスの取れた送信について、信じられないほど誤解していることを示しています。これはスパムのように見えます...
答え2
解決策の 1 つは、配信を待機しているすべてのバウンスを処理するセカンダリ メール サーバーを用意することで、これが実際の電子メールの送信を継続するための最善の解決策でした。
答え3
これは非常に古い質問ですが、テクノロジーはあまり変わっていません。/既存の回答はあまり役に立ちません。
キューに15万～20万件程度のメッセージがあると、私からPostfixへのハンドオフ速度が非常に遅くなります。
この質問の提示方法から判断すると、OPはアクティブキューはここにあります (Postfix には複数のキューがあります)。そして Postfix は、詰まるのを防ぐために、まさに必要なことを行っています。アクティブ キューは、配信スケジュールに関するすべての賢い処理が行われる場所です。キューが大きくなりすぎると、スケジュールがボトルネックになります。
負荷関連のパフォーマンスの問題が見られる場合は、負荷、CPU、および IO メトリックをチェックして、ハードウェアのボトルネックがあるかどうかを確認することをお勧めします。
送信専用リレーを運用している場合、ここで in_flow_delay を減らすと、クライアントのスロットリングが減ります。ただし、アクティブ キューのサイズを小さく保つ必要があります。着信キューからアクティブ キューにメッセージが渡される速度を制限すると、ここで役立ちます。ただし、最善の解決策は、アクティブ キューからより速くデータを取得することです。ここで実行できる最善のことは、適切なレピュテーション管理、高速 DNS、および可能であれば複数の IP アドレスに送信を分散することです。再試行頻度を減らすと、アクティブ キューがいっぱいになる速度や、接続試行の頻度に基づいて受け入れを制限するプロバイダーにも役立ちます。
SPF、DMARC、DKIM（正しく構成されているもの）は必須とみなす必要があります。
誰もがスパムに対処するための独自のメカニズムを発明しているため、常に外れ値が存在し、そのためにカスタムトランスポートを設定する必要があります。