＄vmstat 出力間隔
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
sy-->OS自身使う物
us-->USER使う物
wa-->IO（ディスク、ネットワーク）アクセスの待ち時間割合
id-->idle ボケー時間
procs
r-->実行可能で、実行キューで待つプロセス数
b-->本来実行可能だが、何らかの理由でブロックされた。IO待ちだ！
r-->実行待ちプロセス。これは？？知りたい！！！
＝＝＞
CPU数を超える数のプロセスを実行する(Runinig状態にする)事はできないので、CPUの状態(コンテキスト)を保存したり復元したりするコンテキストスイッチを行い、各プロセスを短い時間単位で実行させる。
で、コンテキストスイッチによりRunning状態だったプロセスが一時的にWaitingに追い出されたりすると、実行可能な状態だけども実行できないプロセスとして実行キューに入った状態になる。
次回の割当てで処理されれば影響は無いが、実行キューに入っているプロセスが多かったり優先度が低かったりとすると一定期間待つ状態が発生する。
このようなCPUを使いたくても使えない(言い換えるとCPUの使用時間が長い)状況下では、サーバ利用者に「重い」と感じさせてしまう。
実行キューに入る要因は、CPU割り当て時間のタイムアウトだけで無く、I/O待ちやロック解放待ちなど他にもある
memory
swpdー＞使用しているスワップ領域の量。どんなにメモリが空いていても、ここの数値が一定の量に達していることがあります。
あまり重要ではない。
buffー>kernelのbuffer領域。メモリ全体が逼迫してくるとここの領域を使う。
cache->hardDiskのキャッシュサイズ。
swap
si->swapから読み込んで、メモリーに展開するデータ量
so->swap out
メモリーが困る時、頻繁にSWAPに注文し、SO、SI高くなる。
io
bi->IOから読んだデータ量
bo->
system
in->割り込み処理の回数
cs->コンテクストスイッチの回数。主にプログラムの実行を切り替えること。一定ののロスが生じるね。空回り時間。。
そもそもそのサーバはどんな使い方をしているのか
・NFSサーバといった用途で使用していて、ファイルアクセスが頻繁なら、syが高くなりがちなのは妥当でしょう
・perlとかphpとかのスクリプト言語、C言語で主に純粋な計算量が多いプログラムを利用しているというようなケースなら、usが高くなることは妥当
・cron等でバッチ処理が多く動作するサーバなら、ぶっちゃけprocsの実行キュー待ちプロセス数やブロックされたプロセス数が増加していてもあまり気にする必要性は高くないと判断することもできます
・一方で、Webサーバ等の用途なら、実行キュー待ちのプロセス数が多くなってくると、利用者からは「重い」と目の敵にされるかもしれません。
・swapについては基本的にはsiとsoは0で有り続けることを至上命題にすべきです。