2012年1月6日金曜日

インフラのお勉強 サーバ障害が起こった時

サーバ障害ってブラックボックスですよね...結局どこに問題があるか分からない,何を調べればいいか分からないというパターンが多いので,問題が起こりそうな勘所を掴むために軽く勉強してみました.

この方法が全てというわけではなく,実際には暗中模索の中,なんとか問題を特定し,解決していく連続になるそうですが,それでも基礎を知ることは指針になると思います.

0.問題の原因の大半はCPU負荷,I/O waitにあり

問題はほぼこの2つなのでまずこの2つが原因なのかその他なのかを調べます

1.topコマンドでロードアベレージを調べる

topコマンドでロードアベレージを調べます.ロードアベレージが低いのに,スループットが悪い場合は,CPUやI/O以外に原因があることが多い(ソフトウェア不具合,ネットーワーク,リモートホストに問題がないかを調べる)


ロードアベレージが高い場合,CPUかI/Oが問題の原因であると思われるので,どちらがボトルネックなのかを探ります

2.sarコマンドでCPU負荷とI/O waitを調べる

CPU負荷が高い場合,ディスクやメモリ容量がボトルネックになっていない理想状態なのにスループットが出ない場合か,プログラムが暴走して(無限ループなど)CPUに必要以上に負荷がかかっている場合のいずれかです.前者の場合はサーバの増設や,ロジック,アルゴリズムを見直す必要があります.

後者の場合,psコマンドなどで暴走しているプロセスを特定し,その部分のコードを修正して対応します

I/O waitが問題な時,スワップの発生なのか,ディスクアクセスが発生しているのかのどちらかが原因です.

スワップが発生している場合,psコマンドで極端にメモリを消費しているプロセスがないかを確認し,そのコードの改善することで対応します

スワップが発生していなくかつディスクアクセスが頻繁に発生している場合は,キャッシュに必要なメモリが不足している可能性があるので,sar -r でキャッシュに必要なメモリがどれくらいであるかを計測し,メモリの増設で対応できる場合であれば,メモリの増設で.コスト的にメモリ増設で対応できない場合はデータの分散をすることで,対応します

この際,データをどのように分散させるか(局所性etc),データ間の同期はどうするかなどの問題があり,複雑になる場合が多く,難易度もかなり高いです.コストと得られるメリットを考え,どのような対策をするかは経営的センスが問われるところでしょう.(はやってるから何でも分散分散では結局コストだけが高くついたりetc)

以上です.ブラックボックスに見える部分も徐々にホワイトボックスにしていく.問題がどこにありそうかの勘所を掴むってのはどんな場合にも重要な気がします.

0 件のコメント:

コメントを投稿