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は後置専用です。

私はそれがincoming-> active-> deferredからキューシャッフルであると思います

質問の詳細：

サーバー：クアッドコアXeon（R）CPU E5405 @ 2.00GH、4 GB RAM

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

16から32の間のPostfixインスタンス

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

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

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

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

プロファイラー（gprof？）の下でpostfixを実行するか、ログを調べます。Postfixは多くのタイミング情報をログに記録し、ホールドアップがどこにあるかを教えてくれます。よく見かける場所は次のとおりです。

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

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

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

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

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

または類似。

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

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

ディスクサブシステムを少なくとも問題の一部として見なければならないようです。postfixが/ varの周りのファイルをシャッフルする方法のため、ファイルシステムレベルでパフォーマンスを上げられないかどうかを確認するために、「少なくともext3ファイルシステムを調整」（少なくともnoatimeとライトバックを設定）をググリングすることをお勧めします。

顧客宛の電子メール用にDNSとアウトバウンドSMTPを2倍にし、そのようなI / Oバインドアップに近いところに毎日250kメッセージ（2k〜10k /時間）を実行するサーバーのクラスターが2つあります。

ストレージパフォーマンスのボトルネックのように見えます。

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

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

またはで始まる

vmstat 1

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

あなたの統計から明らかに高速なディスクサブシステムがいいでしょう。6〜8個の15k rpmディスクでraid-10を使用し、いくつかのキャッシュとオンボードのメモリギガをいくつか使用します。

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

ブライアン

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

ジェームス

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

ボックス内のコアの数と実際の負荷はどれくらいですか？メッセージが送信される実際のレートはいくらですか？

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

ただし、ネットワークの使用率が原因である可能性があります。また、割り込みの負荷が高い（カードが不良ですか）ので、それらを確認してください。控えめなメールサーバーであっても、同じボックスに高速キャッシュDNSサーバー（私は「バインドされていない」）があることで、待ち時間とネットワーク負荷を軽減できることがわかりました。

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

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

これはIOの問題ではなく、後置構成の問題です。一度にすべてをやりすぎて、自分のボトルネックを作成するように求めています。postfixパフォーマンスチューニングの readmeを確認するか、main.cfを投稿してください。

あなたは危険なディスクを持っているように見えます。サーバーは、72の読​​み取り要求/秒と42の書き込み/秒のみを実行します。私のseagate 7200 RPMデスクトップHDDは、1秒あたり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を試してください（Googleの8.8.8.8またはOpenDNSを試すことができます：208.67.222.222）

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

5. コンソールが応答するかどうかを教えていただけますか（たとえば、コマンドを入力するとき、システムはどのくらい速くフィードバックを返しますか）？

   通常、ネットワークの問題（DNSなど）により負荷が急上昇しますが、システムは依然として応答します。