2016.03.07

Webサイトにトラブルが!?コマンド駆使してサーバーの中から問題切り分け

160307_serverfailure_main

みなさん、こんにちは。
Startup.Tokyo Inc.の吉岡朗です。
Webサイト運営時で、簡単なサーバー障害の切り分け方法(後編)の今回はOSレベルのコマンド関連の説明を行います。

Ⅰ.はじめに

OSレイヤーでは、「パフォーマンスが遅れているか」「エラーログが出力されているか」の観点で確認するといいでしょう。
OS内部のリソース状況を確認して、パフォーマンス劣化があるかどうか確認してみます。それぞれ詳しく見ていきましょう。

160307_serverfailure_11図1 リソース状況


Ⅱ.topコマンド~CPUとプロセスから調べる

topコマンドは、CPUとプロセスのリアルタイムな状況を概要レベルで確認するコマンドです。
得られる情報は、システム全体の負荷、プロセス, CPU, メモリー, スワップの統計情報です。

160307_serverfailure_12図2 topコマンドの実行結果

<説明>
1行目:全体的な情報

160307_serverfailure_13図3 topコマンドの1行目

①現在時刻
②サーバーの稼働時間
③ログインユーザー数、
④ロードアベレージ
左から直近1分間、5分間、15分間の単位時間あたりの待ちプロセス数

2行目:プロセス数の情報

160307_serverfailure_14図4 topコマンドの2行目

①プロセス全体の合計
②プロセスで稼働中の数
③プロセスで待機中の数
④プロセスで停止中の数
⑤プロセスでゾンビの数

<<注意事項>>瞬間的な数値を表すので、目安でとどめましょう。

3行目:CPU統計情報

160307_serverfailure_15図5 topコマンドの3行目

①ユーザーモードで稼働中のCPU実行時間
②システムで稼働中のCPU実行時間
③実行優先度を変更したプロセスがユーザーモードでCPU実行時間
④アイドリング状態のCPU実行時間
⑤I/Oの終了待ちをしているCPU実行時間
⑥ハードウェア割り込み要求でのCPU実行時間
⑦ソフトウェア割り込み要求でのCPU実行時間

4行目:メモリーの情報

160307_serverfailure_16図6 topコマンドの4行目

①メモリーの合計サイズ
②メモリーの使用サイズ
③メモリーの空きサイズ
④メモリーのバッファ使用サイズ:mallocなど、バッファとして利用されているメモリー量

5行目:スワップの情報

160307_serverfailure_17図7 topコマンドの5行目

①スワップの合計サイズ
②スワップの使用サイズ
③スワップの空きサイズ
④スワップのキャッシュ使用サイズ:ファイルシステムのキャッシュ

6行目~:プロセス別の情報

160307_serverfailure_18図8 topコマンドの6行目以降

①実行しているプロセスの番号
②実行しているプロセスのユーザー名
③優先度
④相対優先度:0が基準で、負だと優先度が高く、正だと優先度が低い。
⑤仮想メモリー:確保されたメモリーサイズ。スワップしたメモリーも含む
⑥物理メモリー:実際に使用されたメモリーサイズ
⑦共有メモリー
⑧プロセスステータス:
 D: 割り込み不能
 R: 実行中
 S: スリープ状態
 T: 停止中
 Z: ゾンビプロセス
⑨CPU使用率
⑩メモリー使用率
⑪実行時間
⑫現在実行しているコマンドの名前


Ⅲ.vmstatコマンド~CPUやメモリーの負荷状況・使用状況を確認する

vmstatコマンドは、CPU使用状況(負荷状況)とメモリーとI/O状況を時系列で確認するコマンドです。

160307_serverfailure_19図9 vmstatコマンドの実行結果

<説明>
①procs アクティブなプロセスの情報
 r:実行待ち状態のプロセス数
 b:割り込み不可能なスリープ状態のプロセス数
 w:スワップアウトしている実行可能なプロセス数
memory メモリーの使用量と使用可能量の情報
 swpd:仮想メモリー量
 free:空きメモリー量
 buff:バッファとして用いられているメモリー量
swap スワップの情報
 si:ディスクからスワップインしているメモリー量
 so:ディスクにスワップしているメモリー量
io デバイスとの転送量
 bi:ブロック・デバイスから受け取ったブロック数
 bo:ブロック・デバイスに送られたブロック数
system システム全体の割り込みおよびコンテキストの切り替え回数
 in:毎秒の割り込み回数
 cs:毎秒のコンテキスト・スイッチ回数
⑥cpu CPUの使用量
 us:ユーザー時間
 sy:システム時間
 id:アイドル時間
 wa:IO待ち時間
<<注意事項>>⑤のCPU項目はtopコマンドの「CPU」項目と同じです。


Ⅳ.mpstatコマンド~各CPUコアの使用率を確認する

160307_serverfailure_20図10 mpstatコマンドの実行結果

<説明>
①時刻 表示、あるいは取得したときの時刻
②CPU番号。ALLの場合は、全CPUの平均値であることを示す。
③ユーザーレベル(アプリケーション)のCPU使用率
④nice優先順位に従ってユーザーレベルでのCPU使用率
⑤システムレベルのCPU使用率
⑥ディスクI/Oによる待ち時間の割合
⑦ハードウェア割り込みに費やしたCPUの処理時間の割合
⑧ソフトウェア割り込みに費やしたCPUの処理時間の割合
⑨他の仮想プロセッサに処理を割り当てられたために起こる待ち時間の割合
⑩仮想プロセッサを実行するためにCPUが費やした時間
⑪アイドル状態の割合
<<注意事項>> たくさんのCPUを搭載しており、個別のCPUデータを取得する場合には、mpstat -P allで結果が得られます。

160307_serverfailure_21図11 mpstatコマンドで全てのCPUで結果が欲しい場合


Ⅴ.freeコマンド

メモリーの状況を確認するコマンドです。

160307_serverfailure_22図12 freeコマンドの実行結果

<説明>
上段:mem ページキャッシュとバッファキャッシュを考慮しないメモリーサイズ
 ①total:全物理メモリー量
 ②used:使用しているメモリー量
 ③free:未使用のメモリー量
 ④shared:共有メモリーに割り当てられたメモリー量
 ⑤buffers:バッファキャッシュに割り当てたメモリー量
 ⑥cached:ページキャッシュに割り当てたメモリー量
中段:ページキャッシュとバッファキャッシュを考慮したメモリーサイズ(通常は使用せず)
下段:swap スワップに割り当てたサイズ
 ①total:スワップに割り当てたディスクサイズ。
 ②used:割り当てた中で使用中のサイズ
 ③free:割り当てた中で使用していないサイズ。


Ⅵ.エラーのログが出力されていないかどうか

パフォーマンス劣化がなくても、エラーとしてログに出力されていることもあります。確認してみましょう。
ログの出力先は、Linuxのディストリビューションや異なるOS、によって出力先が異なります。
ここでは、一例でGMOクラウド ALTUS BasicシリーズにあるLinuxのCentOS 6.7とします。(1)ウェブサーバー apache
   ログ出力先:/var/log/httpd/
   仮想ホストを利用している場合には、/var/www/vhosts/(仮想ホスト名)/logs
   設定ファイル:/etc/httpd/conf/httpd.conf
(2)データベース MySQL
   ログ出力先:/var/log/mysqld.log
   設定ファイル:/etc/my.cnf
(3)リバースプロキシ Nginx
   ログ出力先:/var/log/nginx/
   設定ファイル:/etc/nginx/nginx.conf
(4)CMS・ブログツール WordPress
   ログ出力先:なし
   設定ファイル:WordPressをインストールしたディレクトリ/wp-config.php
   設定設定ファイル上より84行目前後にあるdefine(‘WP_DEBUG’, false); をtrueに変更することで、画面に出力することができます。本番環境やテスト環境などを加味したうえで、ご利用ください。

160307_serverfailure_23図13 WordPressのエラーログの出し方


Ⅶ.トラブル発生時のフローチャート

トラブル発生時のフローチャートは、図14のような流れになり、今回ご紹介ウェブサーバー上の切り分けの流れは図15のようになります。

160307_serverfailure_24
図14 トラブル発生時の運用フローチャート


160307_serverfailure_25図15 ウェブサーバー障害時のフローチャート

この記事を書いた人

吉岡朗

吉岡朗

Startup.Tokyo Inc代表、HackathonPost.com主宰、WordPress-News.info編集長
一般企業のサラリーマンでシステムエンジニアをしながら、ハッカソン、スタートアップ系に興味を持ちはじめ、個人メディアとして、2014年3月より、【ハッカソン・アイデアソン・起業/ビジネスコンテストのイベント情報まとめサイト「HackathonPost」」を開設。
WordPressを中心に、クラウドサービスを借りながら、50サイト以上のWordPressを運用中。
色々改造して金にならないことばかりして遊ぶエンジニア。
サイト:http://startup.tokyo/
Facebookページ:http://www.facebook.com/HackathonPost

インタビュー記事

この記事を書いた人

吉岡朗

吉岡朗

Startup.Tokyo Inc代表、HackathonPost.com主宰、WordPress-News.info編集長
一般企業のサラリーマンでシステムエンジニアをしながら、ハッカソン、スタートアップ系に興味を持ちはじめ、個人メディアとして、2014年3月より、【ハッカソン・アイデアソン・起業/ビジネスコンテストのイベント情報まとめサイト「HackathonPost」」を開設。
WordPressを中心に、クラウドサービスを借りながら、50サイト以上のWordPressを運用中。
色々改造して金にならないことばかりして遊ぶエンジニア。
サイト:http://startup.tokyo/
Facebookページ:http://www.facebook.com/HackathonPost

IoTの窓口

docker-tips_bnr

writer