web-dev-qa-db-ja.com

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は最小限です

16〜32のPostfixインスタンス

performancepostfixperformance-tuning
11
Brian G

これは少しおかしく聞こえるかもしれませんが、次のことを行う必要があります。

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

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

代わりに、できるだけ多くの高速ディスクを追加します。与えられた情報で必要な数を実際に見積もることはできません。上記の「iostat」出力から、 'sdb'（r/sとw/sの合計）に対して〜120 IOPSを実行しているようです。 1つの15k RPM SCSIまたはFCディスクが150 IOPSを処理すると合理的に見積もることができます。私は5つの15k RPM SCSIディスクと適切なRAIDコントローラから始めます。 1つのホットスペアを持つ4つのドライブにわたってRAID-10としてセットアップします。これで問題が完全に解決されるかどうかはわかりませんが、問題がさらに悪化することはありません。

4
Andrew

プロファイラー（gprof？）でpostfixを実行するか、ログを確認します。 Postfixは、停滞がどこにあるかを教えてくれるかもしれない多くのタイミング情報を記録します。よく見る場所は次のとおりです。

  1. ディスクのパフォーマンス。キューのRAID-10の時間かもしれません。
  2. あらゆる種類のネットワークIO= DNSブラックリスト？SAV？
  3. インストールしたMilterおよびその他のフィルター。
  4. ネットワーク上またはプロセス（ldap、sql）に対して行われる認証とUIDルックアップ。
  5. プロキシを使用しない：遅いマップ（上記のような）
2
Bill Weiss

スループットが一定であると仮定すると、1日あたり100万件のメッセージは1秒あたり約11です。 Postfix自体は、エントリレベルのサーバーハードウェアよりも少なくとも1桁大きい値を処理できます。したがって、postfixが実行されているだけではなく、スループットのピークが非常に不均一に分散しているだけではないかと思います。

あなたの状況は確かに、I/Oが非常に多いサーバーのようです。これはMTAで予想されることです。MTAは、メールを失わないことを保証するために大量の小さな書き込みを行う必要があります。

両方のI/Oを調整する時間を取ってください/var/spool/postfixおよび/var/log。ビジーなPostfixサーバーのベストプラクティスは、異なる2つのスピンドル間で2つを分離し、非同期ログが有効になっていることを確認することです。 Linuxでは、メールログのログファイル名の先頭にダッシュを付けます。

mail.info                              -/var/log/mail.log

または類似。

Amavisd-newを使用している場合は、その作業領域がtmpfsファイルシステム上にあることを確認してください。通常は/tmp/vscan/。ダウンストリーム（ポストフィルター）ホップがメッセージを受け入れるまで、amavisd-newはデータの終わりの応答を返さないため、これは安全です。

Postfixスプールにnoatimeマウントオプションを推奨する人もいます。 postfixがファイルシステムのセマンティクスに依存する方法が原因で、これは潜在的に賢明ではありません。たとえば http://archives.neohapsis.com/archives/postfix/2006-01/1916.html を参照してください。

2
Rob Chanter

間違いなく、ディスクサブシステムを少なくとも問題の一部として見る必要があるようです。 postvarが/ varの周りでファイルをシャッフルする方法のため、「Tweak ext3 filesystem」（少なくともnoatimeとwritebackを設定）をグーグルして、ファイルシステムレベルでパフォーマンスを向上できないかどうかを確認することをお勧めします。

私は2つのサーバークラスタを使用しており、顧客宛のDNSとアウトバウンドSMTPを二重に使用し、そのようなI/Oバインドに近い場所ではなく、毎日250kメッセージ（2k-10k /時間）を実行しています。

1
Greeblesnort

1秒あたり630回の読み取りと1042回の書き込みを行う場合、システムのメモリを増やし（OSとRAMドライブをより適切に処理するため）、postfixフォルダをRAMディスクにすることをお勧めします。

また、完全に独自のディスクでない場合は、独自のパーティションにメールログを配置することをお勧めします。

0
grufftech

これはIO問題ではありません。Postfix構成の問題です。一度に多くのことを実行しすぎて、ボトルネックが発生するように要求しています。--- postfixパフォーマンスチューニング readmeおよび/またはmain.cfを投稿してください。

0
toppledwagon

またはで始まる

vmstat 1

moshenが提案した「iostat 1」も良い

あなたの統計から明らかにより速いディスクサブシステムは素晴らしいでしょう。 6-8の15k rpmディスク上のraid-10は、おそらくいくつかのキャッシュ、オンボードのメモリの数ギグで。

noatime、nodiratimeオプションを使用してスプールディレクトリをマウントします。ファイルシステムを調整または変更して、多数の小さな[私は]ファイルを処理することを検討してください。

0
pQd

同梱されているコアの数、および実際の負荷はいくつですか？メッセージが送信される実際のレートはどのくらいですか？

ほとんどの場合と同様に、私の最初の考えはディスクなので、それを確認してください。

ただし、ネットワーク負荷が原因である可能性があります。高い割り込み負荷（不良カード？）が考えられるため、それらを確認してください。ささやかなメールサーバーでも、同じボックスに高速キャッシュDNSサーバー（私は "unbound"に部分的です）を置くと、待ち時間とネットワーク負荷を軽減するのに役立ちます。

0
Geoff Fritz

収納性能のボトルネックに見えます。

99.88のiowaitは、システムがストレージの待機に多くの時間を費やしていることを示しています。

私はビル・ワイスに同意します。キューのraid10設定を調べる必要があります。

0
3dinfluence

あなたは危険なディスクを持っているように見えます。サーバーは72の読み取りリクエスト/秒と42の書き込み/秒しか実行しません。私のSeagate 7200 RPMデスクトップHDDは、毎秒100以上のランダムな読み取り/書き込み要求を実行でき、それでも対応できます。

スプールをsdaにマウントして、負荷が改善されるかどうかを確認してください。

しかし、ディスクにさらにお金をかける前に、次のことを行ってください。

  1. Qshape active、qshape deferred、qshape incomingを実行して、各コマンドの合計をお知らせください。

    延期キューに異常に多くのメールがある場合、スパマーがメールサーバーを使用してスパムを中継する可能性があります（たとえば、存在しないドメインにメールを送信すると、Postfixが何度も再試行されます）。

  2. メールサーバーがブラックリストに登録されていないことを確認してください（ http://www.mxtoolbox.com/blacklists.aspx ）

  3. DNS応答時間を確認し、ローカルDNSキャッシュを実行します。

    メールサーバーはDNSをかなり頻繁に使用します。行う Dig somedomain.com mxいくつかの異なるホストで実行します。通常、応答時間は100〜400ミリ秒未満である必要があります。より高い応答が得られた場合、DNSは適切に機能しない可能性があります。別のDNSを試してください（グーグルの8.8.8.8またはOpenDNS：208.67.222.222を試すことができます）

  4. ネットワークを確認してください。 （ifconfigなど）、エラーパケットの数を確認します。リンクが飽和しているか成形されているかを確認します。メールログで多数のタイムアウト操作があったかどうかを確認します。 tcpdumpを実行して、パケットが失われたり再送信されたりしていないことを確認します。

  5. コンソールが応答するかどうか教えてください（たとえば、コマンドを入力したときに、システムがフィードバックを提供する速度）。

    通常、ネットワークの問題（DNSなど）は負荷を急上昇させますが、システムはまだ応答しています。

0
Rianto Wahyudi

ブライアン

より高速なディスクを入手するか、できればRAIDソリューションに移行する必要があります。これはどのようなサーバーですか？

ジェームズ

0
James

スパム+ウイルスフィルタリングのためにamavisを実行している場合は、同時amavisプロセスの数を増やす必要があります。設定によっては、postfix master.cfからのsmtp-amavisプロセスの数と、amavis.confの関連設定の両方を増やす必要がある場合があります。

0
hayalci