第6回 PDツールでシステムの内部情報に迫れ【後編】:障害発生時の金科玉条(3/3 ページ)
過負荷状態となったときOSの内部ではどのような動作が行われているのだろうか。ここでは、幾つかのツールを使用して、ステータスの解釈やデータ分析を行ってみよう。問題を解決するには、まず問題を知れ、である。
ステップ4 プロセスへの影響
発生した遅延の原因がスワップによるI/Oにある、と分かったところで、今度はこの事象が実際にはどのプロセスに大きく影響を与えていたか、topの出力データを使って確認してみよう。なお、プロセスへの影響度を測るには各pid*ごとに総実行時間を算出すれば良いが、これはtopの出力からは難しいため、先に述べたvmstatでbフィールドにカウントされているブロック状態のプロセスを特定してみよう。なお、プロセスの総実行時間を得る場合、topを使用するのではなくtimeコマンドを利用するのが確実である。
図3は取得したtop実行結果の一部である。topの各項目の意味は表3やmanページを参照してほしい。
topの出力からブロックされているプロセスを特定するには、STATフィールドのプロセス状態を示すステータスが「D」となっているプロセスを探せば良い。図3では幾つかのswaptestプロセスがブロックされていることが分かる。
今回のケースではスワップがボトルネックになっているわけだが、これと結びつけられるデータがもう1つ確認できる。STATがDとなっているswaptestと、Sとなっているswaptestでは、RSS、つまり使用している物理メモリサイズが大きく異なっている点である。
swaptestプログラム自体は各子プロセス当たり10Mバイトのメモリアロケーションを行う。一方、STATがSとなっているswaptestのRSSはプログラムどおりの10Mバイトであるが、DとなっているswaptestのRSSは10Mバイトに満たないのである。
これらから、次のような現象が発生しているということが分かる。
- swaptestが10Mバイトのメモリアロケーション要求をする
- 物理メモリが不足しているため、メモリアロケータはスワップによって空きスペースを作ろうとI/Oを発生させる
- I/O待ちのため、プロセスはブロック状態となる
このとき、STATがDとなったプロセスはI/Oが終了し、メモリが利用できるようになるまで実行再開ができないため遅延が発生するのである。
ステップ5 ボトルネックの解消
スワップに関するボトルネックの解消には、以下の3つの方法が効果的である。
- スワップデバイスの分散
- メモリの追加
- プロセス単位のメモリ使用量削減
Linuxにおけるスワップ処理は主にカーネルプロセスのkswapdが行うが、しばしば性能面でのパフォーマンス劣化が取りざたされる。カーネル2.6になってページ参照のアルゴリズムは大幅に進歩し、その効果も上がってはいるものの、スワップ周りの性能を構成面、設計面で配慮するに越したことはない。
1の「スワップデバイスの分散」は、単にパーティーションやディスクを分割するのではなく、デバイスのコントローラーやチャネルを分割するほか、バスの帯域やコントローラーキャッシュを分散することで物理ディスクへのI/O性能を考慮することを示唆している。
2の「メモリの追加」は、物理メモリ領域の枯渇状態を軽減し、スワップそのものを減少させることを目的としている。
3の「プロセス単位のメモリ使用量削減」は、必要なデータセグメント*を最小限にするプログラム設計や起動プロセスの削減、子プロセスのスレッド化などが該当する。
今回のまとめ
2回にわたってシステムに負荷をかけた状態で発生する遅延、というトラブルケースをシミュレーションし、実際にツールを使ってPDを行う例を紹介した。また、ツールの使用方法だけでなく、ステータスの解釈やデータ分析方法にも足を踏み入れている。もちろん、今回の例が問題のすべてではないし、実際に発生するさまざまなケースでは、その状況によって解釈や分析結果も変わってくる。そのため、トラブルを実際に作らなくとも日々のオペレーションやベンチマーク時などにリソース情報を収集し、カーネルの挙動を理解することをお勧めする。
次回はカーネルのプロファイリングを取り上げ、より深いシステム内部の動きを観察する予定だ。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このページもしくは表内で出てきた専門用語
pid
Process ID。各プロセスが固有に持つID。
データセグメント
プログラム中で使用するデータが格納されるメモリ領域。
本記事は、オープンソースマガジン2006年2月号「Linux PD−問題判別脳力養成道場」を再構成したものです。
関連記事
- 連載第1回:PD思考法の基礎と情報収集(その1)
Linux環境で問題が発生した場合、管理者がするべきことは「その原因がどこにあるか」の正確な把握である。今回は、発生した問題に対し原因がどこにあるかを判別するための基本的な考え方と、問題判別に必要な情報収集の基礎について解説しよう。 - 連載第2回:PD思考法の基礎と情報収集(その2)
- 連載第3回:ハードウェアかOSか、それが問題だ
I/O関連のトラブルやカーネルパニックなどの原因にハードウェアがかかわっているのは多々あることだ。しかし、実際にそのような状況に直面した場合、どのように原因を探れば良いだろうか。今回から2回に分けて、PDに必要なハードウェア関連情報の収集方法について解説しよう。 - 連載第4回:ハードウェアかOSか、それが問題だ――ハードウェアRAIDを監視する
- 連載第5回:PDツールでシステムの内部情報に迫れ【前編】
PDを行う際に心強い味方となってくれるのがさまざまなツール類だ。ツールを利用することで、ログや設定ファイルからだけでは分からないシステムの内部情報についても知ることができる。そこで今回は、過負荷状態となったときOSの内部ではどのような動作が行われているのか、幾つかのツールを使用して探ってみよう。
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.