☰

Postfix のパフォーマンス

tag-icon • tag-icon performance postfix performance-tuning
Postfix のパフォーマンス

Ubuntu で postfix を実行して、1 日に大量のメール (約 100 万通) を送信しています。負荷は非常に高いのですが、CPU とメモリの負荷はそれほど大きくありません。同じような状況で、ボトルネックを解消する方法を知っている人はいませんか?

このサーバー上のすべてのメールは送信用です。

ボトルネックはディスクにあると想定する必要があります。

最新情報ですが、iostat は次のようになります。

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.12   99.88    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    12.38    0.00    2.48     0.00   118.81    48.00     0.00    0.00   0.00   0.00
sdb               1.49    22.28   72.28   42.57   629.70  1041.58    14.55   135.56  834.31   8.71 100.00

これらの数値は、単一のディスクから期待されるパフォーマンスと一致していますか?

sdb は postfix 専用です。

キューのシャッフル、つまり受信→アクティブ→延期ということだと思います

質問の詳細:

サーバー: クアッドコア Xeon(R) CPU E5405 @ 2.00GH、4 GB RAM

負荷平均: 464.88、489.11、483.91、4 コア。ただし、メモリ使用率と CPU は最小限です。

Postfixインスタンス数16～32

答え1

ちょっとおかしいように聞こえるかもしれませんが、次のことを実行してください。

  1. ログ記録を必要最小限に抑えます。syslog が mail.err 以上のみをログに記録するようにします。
  2. RAM を追加します。確かに Postfix には RAM は必要ありませんが、RAM を追加するとカーネルのページ キャッシュも追加されます。
  3. /dev/sdb 上のファイルシステムについては触れていませんが (これも重要です)、必ず に切り替えてください。noatimeこれにより、負荷が少なくとも少しは軽減されるはずです。
  4. /var/spool/postfix の大きさを確認します。数ギガ未満の場合は、RAM ディスクに移動することを検討してください。

答え2

「/var/spool/postfix」に RAM ディスクを使用するよう提案した人たちには同意できません。これは、メール キュー全体が RAM に保存されることを意味します。サーバーがクラッシュしたり、電源が落ちたりすると、キュー内のメッセージは永久に失われます。メッセージはすでに正常に配信を受け付けているため、クライアント/ユーザーの観点からすると、これは非常に悪い状況です。さらに悪いことに、サーバーが復旧したときにキューが空になっているため、メールがバウンスした、または配信できなかったという通知がサーバーから送信されません。

代わりに、できるだけ多くの高速ディスクを追加することをお勧めします。提供されている情報から、必要なディスクの数を正確に見積もることはできません。上記の「iostat」出力から、'sdb' に対して約 120 IOPS (r/s と w/s の合計) を実行しているようです。1 台の 15k RPM SCSI または FC ディスクで 150 IOPS を処理できると合理的に見積もることができます。まず、5 台の 15k RPM SCSI ディスクと適切な RAID コントローラを用意します。4 台のドライブに 1 台のホット スペアを使用して RAID-10 として設定します。これで問題が完全に解決するかどうかはわかりませんが、悪化することは絶対にありません。

答え3

postfix を何らかのプロファイラ (gprof?) で実行するか、ログを調べます。Postfix は多くのタイミング情報をログに記録し、どこで遅延が発生しているかを示します。一般的に調べる場所は次のとおりです。

  1. ディスク パフォーマンス。キューに RAID-10 を導入する時期かもしれません。
  2. メッセージ上のあらゆる種類のネットワーク IO。DNS ブラックリスト? SAV?
  3. インストールした Milter およびその他のフィルター。
  4. 認証と UID 検索はネットワーク経由またはプロセス (ldap、sql) に対して実行されます。
  5. プロキシを使用しない: 遅いマップの場合(上記のような)

答え4

ディスク サブシステムは、少なくとも問題の一部として確認する必要があるようです。postfix が /var 周辺のファイルをシャッフルする方法のため、ファイルシステム レベルでパフォーマンスを向上できないかどうかを確認するには、「ext3 ファイルシステムの調整」(少なくとも noatime と writeback の設定) を Google で検索することをお勧めします。

私は、顧客宛ての電子メール用に DNS と送信 SMTP の両方の役割を担う 2 つのサーバー クラスターを所有しており、このような I/O バインドアップにはまったく近づかずに、毎日 25 万件のメッセージ (2,000 ～ 10,000 件/時間) を処理しています。

関連情報