CPUの処理の状況を調べるためには、sar (sar -u)が有効であることを前のエントリで書いた。次はメモリの使用状況を調べてみる。まず見てみるのは、メモリとスワップの使用状況を示す sar -r の結果である。
[doublemarket@hoge ~]$ sar -r
Linux 2.6.18-194.8.1.el5 (hoge) 2011年02月15日
00時00分01秒 kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
00時10分01秒 12964 497568 97.46 30880 107440 1984336 63940 3.12 16392
00時20分01秒 13064 497468 97.44 30972 107376 1984336 63940 3.12 16392
00時30分01秒 12692 497840 97.51 31092 107236 1984336 63940 3.12 16392
:
:
20時20分01秒 43756 466776 91.43 45624 139552 1984336 63940 3.12 16288
20時30分01秒 27008 483524 94.71 46420 147608 1984336 63940 3.12 16288
20時40分01秒 22664 487868 95.56 46840 148920 1984336 63940 3.12 16288
20時50分01秒 22300 488232 95.63 47192 148968 1984336 63940 3.12 16288
平均値: 84267 426265 83.49 32592 129944 1984336 63940 3.12 16300
それぞれの列の意味は以下の通り。
kbmemfree
物理メモリの未使用KB。
kbmemused
物理メモリの使用済みKB。
%memused
物理メモリの使用率。Linuxでは、使用されていないメモリ領域をファイルシステムキャッシュ領域として使用するので、通常はほとんどfree部分はないものと考えてよい。従って、常に90数%といった高い使用率になる。実際にアプリケーションの動作に使われているメモリの量は、下の指標を確認する必要がある。
kbbuffers
カーネルがバッファ領域として使用しているメモリ量のKB。
kbcached
カーネルがキャッシュとして使用しているメモリ量のKB。kbmemusedからkbbufferesとkbcachedを引いた値が、実際にアプリケーションに割り当てられているメモリ量ということになる。逆に言えば、kbbufferesとkbcachedの容量が、kbmemusedの大部分を占めているようなら、アプリケーションにとってメモリ不足とは言えないということになる。
kbswpfree
スワップ領域の未使用量KB。
kbswpused
スワップ領域の使用済みKB。
%swpused
スワップ領域の使用量。通常ほとんど0だが、物理メモリが不足してくると使用率が上がってくる。数%であれば実質的にシステムの動作には影響がない場合が多いが、あまり多いようだと、スワップ領域へのアクセスが頻発している可能性もあり、システム全体のスループットを落とすことがある。%swpusedが大きく、かつsar -uのiowaitの値も大きい場合、ほぼ間違いなくスワップ領域へのアクセスでスローダウンしているので、物理メモリの増設などのメモリ不足解消策を取る必要がある。
kbswpcad
何の指標かよく分からなかったが、manページによると、一旦スワップ領域へ飛ばされたものの(スワップアウト)、スワップ領域からメモリに戻され(スワップイン)、かつまだスワップ領域にデータが残っている、というデータの量とのこと。
各列の値の傾向を見ると、上記のようにメモリ不足なのかどうかの手がかりが得られる。その他に詳しい情報を見たいときは、以下のオプションも用意されている。
sar -R
メモリ上のページの使用状況。
sar -W
スワップの発生状況。ページイン(スワップ領域から物理メモリへのページの移動)とページアウト(物理メモリからスワップ領域へのページの移動)がどの程度発生したのかを確認できる。
sar -B
ページングの状況。ページイン・ページアウトされたデータ容量、ページフォルトの回数、メジャーなページフォルトの回数をそれぞれ確認できる。
前回のエントリでは、システムのレスポンスが悪化している場合、まずとっかかりとしてtopコマンドを実行し、ロードアベレージを確認する方法を書いた。さらに踏み込んで、何が負荷の原因なのかを探るために、sarコマンドを使う方法について書く。
sarコマンドをオプションをつけずに実行すると、以下のような出力が得られる。ファイルを指定しないと、コマンドを実行した当日の0:00から直前までの10分おきの情報が表示される。過去の情報は/var/log/saディレクトリ以下に保存されており、「sar -f sa07」などと指定すると、そのファイルに保存された情報が閲覧できる。saの後の数字は日付を表している。
sarを実行してもコマンドが見つからない場合、sysstatパッケージがインストールされていないので、インストールすべし。
[doublemarket@hoge ~]$ sar
Linux 2.6.18-194.8.1.el5 (hoge) 2011年02月15日
00時00分01秒 CPU %user %nice %system %iowait %steal %idle
00時10分01秒 all 0.05 0.00 0.08 0.02 0.00 99.85
00時20分01秒 all 0.03 0.00 0.08 0.02 0.00 99.88
00時30分01秒 all 0.07 0.00 0.11 0.02 0.00 99.79
:
:
20時00分01秒 all 0.03 0.00 0.06 0.00 0.00 99.90
20時10分01秒 all 0.06 0.00 0.11 0.03 0.00 99.80
20時20分01秒 all 0.16 0.00 0.14 0.03 0.00 99.67
20時30分01秒 all 1.11 0.00 0.27 0.12 0.00 98.50
20時40分01秒 all 0.08 0.00 0.12 0.05 0.00 99.76
平均値: all 0.08 0.00 0.10 0.09 0.00 99.73
ここで得られる結果は、sar -uと同じものである。それぞれの列の意味は以下の通り。
user
ユーザプログラムの実行に使用されたCPUリソースの割合
nice
niceによる優先度を処理するために使用されたCPUリソースの割合
system
カーネルが使用したCPUリソースの割合
iowait
I/O待ちの割合
idle
I/O待ち以外でCPUが待ち状態だった割合(何もしていない時間)
なお、マルチCPUの環境の場合ここに表示されているのは、全CPUの合算使用率になっている。それぞれのCPUの使用率を確認したい場合、「sar -P ALL」を実行する。意外と処理が特定のCPUに偏っていたりするので、こちらも確認してみた方がよい。
→ sarコマンドの実行結果からシステムの負荷状況に関して、以下の傾向がつかめる。
userの値だけが高い(他の値は低いまま)
CPUリソースを必要とするアプリケーションが動作している。
topやps auwxなどのコマンドでプロセスごとのCPU使用率を調べ、無限ループなどの不具合によるCPU使用率の上昇でないかなど、異常を確認。単に処理が重くなっているだけなら、スケールアップ(CPUを高速化)、スケールアウト(マシンを増設)を検討する。
iowaitの値が高い
そのマシンに求められる処理に対して、ハードディスクの速度が追いついていない。アプリケーションやミドルウェア(特にデータベースなど)のキャッシュの仕組みを見直したり、読み書きに使う物理的なディスクを分散させるなどして、なるべくディスクの読み書きが発生しない方法を考える。それでも高いままなら、より高速なディスクを使うしかない。なおたいていの場合は
・アプリケーション自体がディスクにアクセスする速度が遅い
・メモリが不足していてスワップ領域(つまりディスク)へのアクセスが頻発していて遅い
の2つに問題を分けることができる。このうちのどちらかという判断は、sar -rの結果などを見る必要がある。
systemの値が高い
仕組み的にいえば、コンテキストスイッチがたくさん発生していると値が上がるはずなので、必要以上にたくさんのプログラムを並列に処理しすぎていると、この値が異常に上がるということになるが、よく分からない。
sarコマンドには、メモリやディスク、ネットワークなどに関する情報が得られるよう、他にも色々なオプションがある。
Linuxにおいて、システムの全体的な負荷状況を知りたい時、リアルタイムの状況を知るにはtopコマンド、ある程度の期間に渡る傾向をつかむにはsar(sysstat)の結果を確認するのが一般的だろう。
そのサーバ上で動作するアプリケーションの動作が遅いなどといったパフォーマンス劣化がある時、まず最初に見るべきがロードアベレージの値。これは「CPUの処理を待っているタスクの数」であり、ほとんど何も処理を行っていない時には0になる。
topコマンドの表示内容
top - 16:04:44 up 15 days, 21:40, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 108 total, 2 running, 105 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 8113608k total, 8082584k used, 31024k free, 69652k buffers
Swap: 8385920k total, 352k used, 8385568k free, 6008888k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 16 0 1848 552 472 S 0.0 0.0 0:01.32 init
2 root RT 0 0 0 0 S 0.0 0.0 0:17.52 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.40 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:15.31 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:00.32 ksoftirqd/1
6 root RT 0 0 0 0 S 0.0 0.0 0:11.21 migration/2
7 root 34 19 0 0 0 S 0.0 0.0 0:00.17 ksoftirqd/2
8 root RT 0 0 0 0 S 0.0 0.0 0:15.26 migration/3
9 root 34 19 0 0 0 S 0.0 0.0 0:00.25 ksoftirqd/3
10 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/0
11 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/1
12 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/2
13 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 events/3
14 root 7 -10 0 0 0 S 0.0 0.0 0:00.00 khelper
15 root 15 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid
95 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
96 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kblockd/1
1行目の右端に表示されているのがロードアベレージの値。前述の通りCPUの処理を待っているタスクの数がロードアベレージなので、値が大きければ大きいほどCPUの処理を待っているタスクが多いということになり、それだけサーバのレスポンスが落ちることになる。ただし、単に計算を待っているだけではなく、IOの処理を待っている場合もこの値が大きくなるので、ロードアベレージが大きいことが即CPUが遅いことになるわけではない。CPUそのもの、メモリ、ディスク、それ以外、の何が原因で遅いか調査する必要がある。
なお、topでのロードアベレージの表示は、左から、1分、5分、15分間の平均値になっている。つまり、左の方が値が大きければ、直近の数分間で急に負荷が上がっていることを表す。
言わずもがなだが下半分には、CPUの使用率順に並んだプロセス一覧が表示されるので、ここからCPU負荷が高かったりメモリの使用量が多いアプリケーションが何なのかは大体つかめる。topからなんとなくのあたりをつけたあと、何がボトルネックになっているかを探すには、sarコマンドで過去のパフォーマンスデータを確認していく。