EC2インスタンスのUbuntu 12.04でのI / O待機による高負荷

Ubuntuサーバー12.04を使用していますが、負荷の原因を特定できません。サーバーの応答時間に先週の変化がありました。

Linuxトラブルシューティングを読んだ後、パートI：高負荷

CPUとRAMには問題がないようで、この負荷は次の出力を取得 したコマンドを使用して、I / Oバウンドの負荷に関連している可能性がありtopます

ここでは97.6%wa、RAMは解放され、スワップは使用されていません。

以下は、あることを示すコマンドの出力iostatです89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

私はまたiotop、修正間隔が99％I / Oを示した後、ディスクが私がオブザーバーとして書き込んだものを使用しました1266 KB/s

そして

悪いですか 応答時間が低下するにつれて。何が原因ですか？

他から寄せられた編集

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

の出力 iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@shodanshokポイント2

iotop -a

mysqlサービスを調整して、ディスクに触れないようにし、postfixキューに気を付けてください。I/ Oセンシティブキューに大量のメールが送信される可能性があります（つまり、ランダムな読み取り動作を伴う遅延された小さなイテンション）。

あなたのメールシステムはスパマーのリレーとして使用されています。

postfixのドキュメントを見て、MTAへのリレーアクセスを制限してください。

iostatとiotopを使用して収集された追加情報の後に編集
されます利用可能なIOPSが不足しているため、ディスクは100％ロードされています。EC2インスタンス、特に安価なインスタンスは、持続IOPSに強い上限があります（30〜50 IOPSの範囲）。

新しいiotop出力によると、mysqlとbounceの両方が大量のIOPSを消費しています。ただし、iotopの出力は完全ではないか、少なくともソートが不適切です。「iotop -a」を1回はIOPSで、もう1回はディスクの書き込みでソートを再実行できますか？

元の回答
私の賭け：「バウンス」プロセスは、Amazonが提供する仮想ディスクデバイスを窒息させる多くの同期書き込みを発行しています（ところで、どのプロファイルを使用していますか？EC2ディスクには、持続I / OとバーストI / Oについて非常に厳密なルールがあります）。

とにかく、何がI / O帯域幅を消費しているのかを特定することは、ときどきやや難しい場合があります。iotopは非常に優れたツールですが、必要な情報が得られない場合があります。もっと深く掘り下げる必要があります。だから、これらのアドバイスに従ってください：

1. 最初に、処理中のI / Oのタイプと影響を受けるブロックデバイスを特定する必要があります。
   次のコマンドを実行してください：iostat -x -k 5 2。両方の結果セットを報告してください。
2. 次に、I / Oを待っているプロセスを特定する必要があります。
   「トップ」を使用できる場合：起動して、Shift + f（F）、w、Enterキーの順に押してから、Shift + r（R）を押します。最初のプロセスは、DまたはD +状態（つまり、ディスク/ネットワークを待機中）のプロセスです。リストを報告してください。
3. iotopを使用して、プロセスの累積I / O値を表示します。約1分間
   実行iotop -aして、ここに出力を貼り付けます。

少し遅れましたが、同様のマシンで同じ問題が発生し、その問題は破損したMySQLテーブルの集まりであることがわかりました。これらのテーブルの一部には大量のデータが含まれていたため、大量のI / O待機時間が発生しました。

見/var/log/mysql/error.logまたは使用mysqlcheckを見つけるために、修理には、データを破損しました。

上記のように、EC2インスタンスにIOキャップが付いているか、Amazon EBSスタンダードボリュームに基づいている可能性が非常に高いため、IOをあまり提供していません。それを見ていこのページを -それは申し出アマゾン異なるボリュームタイプについて説明します。

遅い種類のボリュームがある場合でも、かなり高速に書き込むことができるはずですが、ロードが本質的にランダムである場合、それが（SQLのもの）である可能性があるため、IOPSをアップグレードすることをお勧めします容量。これは通常、SQLパフォーマンスの上限となるためです。

したがって、数値から見ると、標準のストレージを使用するとIOPSが不足する可能性があります。より高速なストレージを購入しても、それほど高価ではありません。見ていこれを。

ディスクが非DMAモードになっている可能性があります。ドライブのDMAステータスを確認してください。（hdparmコマンド）

そうでない場合、何か他のものが多くの割り込みを生成する可能性があります。古き良きDOS時代のものを覚えている人はいますか？