SSブログ

vmstatの見方と考え方 [Linux(CentOS/VineLinux)]

 なにもここで説明しなくてもvmstatの説明なんてそこらじゅうにある訳ですが、同じコマンドでもカーネルのバージョンとかディストリビューションとかで結構違ってくるので、ここではCentOS5.2でのvmstatについて記載しておくことに。

 vmstatを実行すると…

[root@chihiro ~]# vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0    136  10836   3744 1940256    0    0   174  2050  128   96  1  6 74 19  0
 0  0    136  10456   3720 1940424    0    0     0  6731 6067 7326  0  4 85 11  0
 0  0    136  10028   3700 1940796    0    0     0  6730 6039 7285  0  5 84 11  0

 こんな感じでレポートがズラズラと出力されてきます。
 一番注目されやすい項目としては、末尾にある「cpu」の項目たち。ここは「その時間のうちにどれくらいの割合、CPUを使ったか」というレポートになっています。順番が違いますがこんな意味合いを持ちます。(説明しやすいので並び替えました)
  sy … カーネルコード(OS自身、またLinuxシステムコール等を呼び出された等)の処理のために費やした時間の割合
  us … カーネルコード以外の処理に費やした時間の割合。要するに、一般のプログラムが動いていた時間の割合
  wa … データの入出力処理(ディスクへのアクセス、ネットワークへのアクセス)を試みたものの、結果的にデータを待っていた時間の割合
  id … アイドル時間の割合。要するに「ぼけー」っとしていた時間のこと。


 とかく、ロードアベレージとか、アイドル時間の大小ばかりに目がいきがちですが、それでシステム全体のパフォーマンスをはかるのは早計です。考慮すべき点は他にもあります。

 サーバの利用者から見たとき、そのサーバが「重い」と感じているかどうか、もっと端的に読み取れる項目があります。それはvmstatの最初の項目「procs」です。

 procsの項目:
  r … 実行可能で、「実行キュー」に入っているプロセスの数。
  b … 本来は実行可能なプロセスであるが、何らかの理由で処理を「ブロック」されているプロセスの数

 まず、「実行キュー」とは何かといいますと、Linuxは「時分割」という手法で、複数のプロセスがさも同時に動いているかのように見せる方法を採っています。プログラムA・B・Cと3個あったとして、プロセッサが1個しか無いなら、本当は同時には1個のプログラムしか実行できないはずです。そこで、1個のプログラムがプロセッサを占有する時間をごく短くして、プログラムA→プログラムB→プログラムCと、順番にかわりばんこに処理すると、あたかも3個のプログラムが同時に動作しているように見えるじゃありませんか。
 で、このプログラムの切り替えのために、「実行キュー」という仕組みが用意されていて、駅の券売機か銀行のATMの待ち行列みたく、これから実行してもらえるプログラムが並んで待っている状態を作ります。全てが順調に処理されているなら、通常はこの「実行キュー」に入ったプログラムはほとんど即時に処理されてキューから退出するのですが、CPUが忙しかったりプログラムの実装がアレだったりすると、この「実行キュー」にはいったまま待たされるという状態が生じます。
 実行キューに入ったプログラムは、本当なら実行してもらえたはず(CPUを占有させてもらえたはず)なのに順番が回ってこなかったということになりますので、そのプログラムを使っている人からみると、プログラム(サーバ)からの返事がない(返事が遅い・返事がスムーズでない…)ということを体感してしまうかもしれません。
 以上のことから、procsのrの項目がいつも0じゃない状態が続いているようなら、利用者は「このサーバ、遅いな!」と感じている可能性があります。

 また、本来は実行可能なプロセスであるが、何らかの理由で処理を「ブロック」されているプロセスとは何のことでしょうか。これは、ほとんどの場合は、ディスクやネットワークへの入出力を待っている状態に置かれているプロセスです。しかも、入出力を待っていたら次の自分の順番が回って来ちゃったというようなケースです。
 CPUの挙動に比べたら、ディスクやネットワークへのアクセスというものはもの凄く遅い物です。大きなデータを読んだり書いたり、あるいはいくつものプロセスが同時に読んだり書いたりすれば、それだけアクセス速度は落ちます。そのような状態の時にこの値が大きくなることがあります。
 このような場合も、結果的にプログラムの実行が止まっていることになるので、プログラム(サーバ)の利用者からしたらプログラム(サーバ)からの返事がない(返事が遅い・返事がスムーズでない…)ということを体感してしまうかもしれません。

 サーバのアイドル時間と、プロセスの実行状態とは関連することも多いですが、プログラムの実装次第ではアイドル時間はやたらあるのにサーバが遅いと言われるということもままあります。



 他の項目については、メモリやスワップに関する情報、ブロックデバイスへの入出力頻度等が注目されます。

 memoryの項目:
  swpd : 使用しているスワップ領域の量。どんなにメモリが空いていても、ここの数値が一定の量に達していることがあります。まあ、増減が無ければ(後述する、siやsoの値が0のままなら)それほど深刻に考える必要性は薄いでしょう。
  free : 純粋に未使用状態なメモリの量。メモリを潤沢に搭載していて、大きなプログラムが動作しているわけでもないのに、この値がもの凄く小さくなっている事があります。その場合は、以下のbuffとcacheの値(特にcacheの方)を見てください。
  buff : 主にカーネルがバッファ領域として使用しているメモリ量。それほど大きくなることは無いけども、メモリ全体が逼迫してくるとここの領域を削ってどうにかしようとがんばるようになります。
  cache : ディスクアクセス時にキャッシュデータを保存しているメモリの量。しばらくするとここの値がべらぼうに大きくなるのが一般的です。しかしそれに目くじらを立てる必要はありません。なぜなら、この領域は未使用状態なメモリと同じ扱いだからです。空いてる領域を未使用のままにしておくのはもったいないので、過去のディスクアクセスの際に読んだり書いたりしたデータを保存しておこう…ということに使っているからです。この項目に代表されるキャッシュデータは別に無くなっても深刻じゃない(またあとでディスクから読み出せば良いだけ)ので、メモリを沢山必要になったときにはキャッシュデータを捨ててメモリをプログラムのために割り当てることになります。

 swapの項目:
  si : スワップ領域から読み込んでメモリに展開したデータの量(スワップ・イン)
  so : メモリからスワップ領域に書き込んだデータの量(スワップ・アウト)

 メモリがいよいよ不足してくると、メモリ上にある不要不急のデータやプログラムをディスクに逃がしてメモリを空けようとがんばります。そして、そのデータやプログラムが必要になったら今度はディスクからメモリの上に戻してプログラムを実行したりデータをいじったりします。その挙動がここに現れます。
 si、so共に常時ゼロという状態が基本です。ここに常時数値が現れることは、そのサーバにはメモリが足りないか、メモリをバカ食いするプログラムが多すぎるかのどちらかということになります。

 ioの項目:
  bi : ブロックデバイス(主にディスク等)からの読み取り量
  bo : ブロックデバイス(同上)への書き込み量

 複数のブロックデバイスがあっても、ここではその合計値しか表示されません。

 systemの項目:
  in : 割り込み処理の回数
  cs : コンテクストスイッチの回数

 「割り込み処理」とは、人間の生活でいえば玄関のチャイムとか電話の呼び出しとかキッチンタイマーのベルとかトイレに籠城している父ちゃんの「紙もってこ~い」とかそういった類に似ています。それまでやっていたことを一時的に止めて玄関のインターフォン越しに相手を確認したり、電話に出たり、鍋の状態をみたりしますよね?これをCPUもやっていて、その処理全般のことを「割り込み処理」と言っています。その回数をレポートしています。

 「コンテクストスイッチ」とは、主にプログラムの実行を切り替えることを言います。プログラムの切り替えは、主に
  ・そのプログラムが一度に占有できる時間を使い切った
  ・カーネルに時間の掛かる処理(例えばディスクアクセス)を依頼した
  ・割り込み処理が発生した
  ・プログラムが「自主的に」処理時間を返上した
  ・そもそもプログラムが終わった
 等のタイミングで発生します。なお、この「コンテクストスイッチ」という処理(つまり動作するプロセスを切り替える処理)には一定のロスが生じてしまいます。(これを「オーバーヘッド」と呼んだりします)プログラムを切り替えるためには、そのプログラムが次に実行できるために必要な情報を漏らさず保存しておかなければならず、次に実行する別のプログラムが必要とする情報を漏らさず復元しなければなりません。このような処理は頻発すればするほど、本来のプログラムの実行に使える時間が短くなることを意味します。

 まあ、この2個の項目を見て直ちになんらかのクリティカルな状態にあるかとかそういう判断をすることはまずマレです。ただ、特徴的なくらい飛び抜けて多いとか少ないとか読み取れる場合には、何らかの異常・ボトルネックが生じているかもしれないと判断をするトリガーにはなるかもしれません。




 さて。cpuのidがとても低い状態が悪いことでしょうか?
 確かに、負荷が原因で障害が発生する場合、idが0かもの凄く低い状態であることが多い傾向にあることは事実です。しかし、ここだけを見てサーバに問題があると判断するのは問題があります。
 逆に、idが高いのに重い重いと言われるケースもありえます。

 また、usが高いとか、syが高いとかいうケースも、それが「良い(妥当)」か「悪い」のか、サーバの用途によって判断が分かれる事にも注意が必要です。

 例えば。
 NFSサーバとか、sambaサーバとかといった用途で使用していて、ファイルアクセスが頻繁なら、syが高くなりがちなのは妥当でしょう。一方で、perlとかphpとかのスクリプト言語、C言語で主に純粋な計算量が多いプログラムを利用しているというようなケースなら、usが高くなることは妥当だと判断することになるでしょう。
 また、cron等でバッチ処理が多く動作するサーバなら、ぶっちゃけprocsの実行キュー待ちプロセス数やブロックされたプロセス数が増加していてもあまり気にする必要性は高くないと判断することもできます。一方で、Webサーバ等の用途なら、実行キュー待ちのプロセス数が多くなってくると、利用者からは「重い」と目の敵にされるかもしれません。
 swapについては基本的にはsiとsoは0で有り続けることを至上命題にすべきです。ただ、一時的に目をつむるケースも出てくるかもしれません。例えばデータのバックアップとかファイルの整理などで一時的に大きなプログラムを動かさなければならない時とか。さらにその時間はアクセスが無くて他の人に迷惑をかけないなら、どれだけスワップしようがまあ我慢できる範囲内なら、まあいっか…というような判断もありえます。

 このように、そもそもそのサーバはどんな使い方をしているのかということに着目しつつ、負荷の状態をチェックするべきです。さもなければサーバ管理者とお金がいくらあっても足りないことになりますからね。(笑)
nice!(2)  コメント(0)  トラックバック(1) 
共通テーマ:パソコン・インターネット

nice! 2

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

※ブログオーナーが承認したコメントのみ表示されます。

トラックバック 1

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。