障害時の切り分けでできること(2)

インフラ運用時に発生する障害の切り分け方法についての前回()の続きです。

今回は既に "その1:まずは SSH でログイン"  で OS レベル(+プロセスレベル)での確認が完了している為、さらに OS の中まで覗いた切り分けになります。

その2:top で現在の状況を確認

SSH でログインした後は top コマンドを使います。

top コマンドは通常ロードアベレージ、CPU 負荷等の一覧を表示するコマンドですが、Windows のタスクマネージャ同様このコマンドでロードアベレージが高くないか、異常な動きをしているプロセスがいないかを確認します。

ロードアベレージが高くないのであればもうこのコマンドは必要ありません。"その3:とにかく telnet でポートを叩いてみる"へ進みましょう。

top コマンド例

$ top
top – 21:11:46 up 2 days, 21:26, 1 user, load average: 0.06, 0.08, 0.03
Tasks: 148 total, 1 running, 147 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.7%us, 0.2%sy, 0.4%ni, 97.5%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1546096k total, 1486956k used, 59140k free, 224040k buffers
Swap: 2097136k total, 0k used, 2097136k free, 710312k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 15 0 2072 624 532 S 0.0 0.0 0:00.51 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.30 ksoftirqd/0

この時点で常に CPU が 100% に張り付いてしまっているプロセスがいればこのアプリケーションに異常があると考えて問題ありません。

CPU が 100% になるのは通常 I/O を経由せずに処理していることを意味します。具体的にはファイル入出力を介さない while、for の無限ループ、正規表現のループ等が該当します。このような状況になっている場合は大抵アプリケーション側に問題があると判断していいでしょう。

一方、多いのが I/O 負荷によるロードアベレージ超過です。iowait の値が 30% を超えている状態が続いていたり、50% 以上となる場合はファイル入出力の方が HDD の能力に優ってしまっています。

この場合、ファイル入出力を穏やかにするようアプリケーションを改修するか HDD の回転数を上げる(SAS を利用する等)等の対応が必要になってきます。ただ、"HDD の回転数を上げる" 対応というのは限界があるのであまり進められません(2010/12/16 時点で SAS 15000回転がおおよそ最高)。

アプリケーション側の設計を見直し、キャッシュや RAM を利用したり分散ファイルシステムを利用する等の工夫が必要です。

top による障害切り分け

最後に Swap 行の used が数00メガバイト以上になっていればスワップと判断できます。これは単純に物理メモリが不足している為、メモリを追加すればよいとも言えるのですが、ちょっと待ってください。

この時、プロセスが利用しているメモリ(RES)も確認が必要です。

一プロセスだけが異常にメモリを利用している(数ギガバイト)ようであれば、メモリ不足ではなくアプリケーションのメモリリークもしくはメモリの使い過ぎ状態になります。

Java 系(特に tomcat)ではよく見られますが、すぐ見てあまりにメモリを利用しているようであれば改修が適切と言えます(参照を弱参照にする等)。

top で判断できることはだいたいこの位です。結構 top だけで色々と分かってしまうので障害時に非常に役立つツールと言えます。

【お勧め】監視関連の記事

次のページへ

No Comments - Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

*