EC2インスタンスのUbuntu 12.04でのI / O待機による高負荷
Ubuntuサーバー12.04を使用していますが、負荷の原因を見つけるのに問題があり、サーバーの応答時間に先週からの変化がありました。
読んだ後 Linuxトラブルシューティング、パートI：高負荷
CPUとRAMには問題がないようで、この負荷は、次のようなtopコマンドを使用して、I/O-bound loadに関連している可能性があります出力
ここでは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 documentation を見て、MTAへのリレーアクセスを制限します。
少し遅れましたが、同様のマシンで同じ問題が発生し、その問題は破損したMySQLテーブルの集まりであることがわかりました。これらのテーブルの一部には大量のデータが含まれていたため、大量のI/O待機時間が発生しました。
見る /var/log/mysql/error.logまたはmysqlcheckを使用して、破損したデータを見つけて修復します。
iostatとiotopを使用して収集された追加情報の後に編集
使用可能なIOPSが不足すると、ディスクは100％ロードされます。iostatによると、50 + IOPS（85 w/s-35マージw/s）が一定です。 EC2インスタンス、特に安価なインスタンスは、持続IOPSに強い上限があります（30〜50 IOPSの範囲）。
新しいiotop出力によると、mysqlとbounceの両方が大量のIOPSを消費しています。ただし、iotopの出力は完全ではないか、少なくともソートが不適切です。 「iotop -a」をIOPSで1回、ディスクの書き込みで別の時間にソートして再実行できますか？
元の回答
私の賭け：「バウンス」プロセスは、Amazonが提供する仮想ディスクデバイスをチョークする多くの同期書き込みを発行しています（ところで、どのプロファイルを使用していますか？EC2ディスクには、持続IとバーストI /に対して非常に厳密なルールがあります。 O）。
とにかく、何がI/O帯域幅を消費しているのかを特定することは、ときどきやや難しい場合があります。 iotopは非常に優れたツールですが、必要な情報が得られない場合があります。もっと深く掘り下げる必要があります。だから、これらのアドバイスに従ってください：
- 最初に、処理中のI/Oのタイプと影響を受けるブロックデバイスを特定する必要があります。
次のコマンドを実行してください：iostat -x -k 5 2。両方の結果セットを報告してください。 - 次に、I/Oを待機しているプロセスを特定する必要があります。
そのために「トップ」を使用できる場合：起動し、Shift + F（F）、W、Enterの順に押してからShift + R（R）を押します。最初のプロセスは、DまたはD +状態（つまり、ディスク/ネットワークを待機中）のプロセスです。リストを報告してください。 - iotopを使用してプロセスの累積I/O値を表示。
実行iotop -a約1分間、ここに出力を貼り付けます。
上記のように、EC2インスタンスにIOキャップが付いているか、Amazon EBSスタンダードボリュームが基になっている可能性が高いため、あまり配信されませんIO賢いです このページ -アマゾンが提供するさまざまなボリュームタイプについて説明しています。
遅い種類のボリュームがある場合でも、かなり高速に書き込むことができるはずですが、ロードが本質的にランダムである場合は、SQLのように見える可能性があるため、IOPSをアップグレードすることをお勧めします容量。これは通常、SQLパフォーマンスの上限となるためです。
したがって、数値から見ると、標準のストレージを使用するとIOPSが不足する可能性があります。より高速なストレージを購入しても、それほど高価ではありません。 this をご覧ください。