Solaris 資料一覧
2007/8/15更新
対応バージョン: 10
Solarisシステムが正常に稼働しているかどうかを判断するには日常的な監視が欠かせない。
ここではSolarisシステムを監視するのに必要なコマンドとその結果を分析するポイントについてまとめる。
後半ではシステム性能が悪化した場合の問題点の特定から改善までの流れについて事例を交えて紹介する。
システムの稼働状況を確認するためのコマンド
システム全体の稼働状況やシステムの性能悪化の原因を調査するためにはsarやvmstatコマンドを使用する。
その後psやprstatコマンドを使用し性能を悪化させているプロセスの特定を行う。
問題となっているプロセスが特定できればプロセスの見直し(優先度の変更や実行スケジュールの変更、ユーザプログラムの改善など)を行う。
特に原因となるプロセスが特定できない場合、プロセスの見直しが不可能である場合、性能の悪化が慢性的な場合などはハードウェアの増強を検討する必要がある。
以下はシステム稼働状況の解析に使用する主なコマンドである。
sar
システム全体の稼働状況を確認する
vmstat
システム全体の稼働状況を確認する
mpstat
CPU使用稼働状況を確認する
iostat
ハードディスク、CPUの使用状況を確認する
ps
プロセス情報を確認する
prstat
プロセス情報を確認する
priocntl
プロセスの優先度を変更する
prtconf
システム構成情報を確認する
swap
仮想記憶領域を確認する
sysdef
カーネルパラメータを確認する
各コマンドの使用方法
sar、vmstat、mpstat、iostatコマンドについてはコマンド実行時に「計測間隔」と「計測回数」を指定する。
「計測間隔」の指定についてはコマンド実行によるシステムへの影響を含ませないように、最低でも5秒以上を指定するのが望ましいとされている。
また「計測回数」の指定について以下の実行例では1回のみのデータを採取しているが実際にデータを採取する際は5回(一度に多くの資源が使用される場合)から20回程度(徐々に資源が使用される場合)のデータを採取するとよい。
以下に各コマンドの使用例と、出力結果を分析するためのポイントを紹介する。
sarコマンド
sarコマンドにはいくつかのオプションがあり、そのオプションを指定することによってシステムの稼働状況に関するさまざまな情報が確認できる。
以下のオプションが全てではないが、特に頻繁に使用されるオプションとその出力結果からシステムの稼働状況の問題であるか否か、またパフォーマンス低下の原因は何であるかを判断するための基準値について解説する。
-uオプション
CPUの使用率を確認する。
<実行例>% sar -u 5 1 11:34:24 %usr %sys %wio %idle 11:34:29 95 5 0 0<表示結果>
%usr
ユーザ空間(プロセスの実行に費やされた時間)で使用されたCPUの時間の割合(vmstatのus、mpstatのusrと同等)
%sys
カーネル空間(システムコールなどの処理時間)で使用されたCPUの時間の割合(vmstatのsy、mpstatのsysと同等)
%wio
I/O処理によってCPU処理が待ち状態にあった時間の割合(mpstatのwtと同等)
%idle
CPUが待ち状態にあった時間の割合(vmstatのid、mpstatのidlと同等)
<監視ポイント>%usr + %sys > 90、かつ%usr < %sysの状態が継続する場合
メモリ不足がシステム性能を悪化させている可能性がある。あるいはプロセスがシステムコールを多発してCPUに負荷がかかりシステム性能を悪化させている可能性がある。
%usr + %sys > 90、かつ%usr > %sysの状態が継続する場合
ユーザプロセスの異常動作によってCPUに負荷がかかりシステム性能を悪化させている可能性がある。
%wio > 10の状態が継続する場合
ハードディスクなどのI/O装置の性能が不足しているためI/O処理がシステム性能を悪化させている可能性がある。
-qオプション
プロセスキューの状況を確認する。
<実行例>% sar -q 5 1 11:31:53 runq-sz %runocc swpq-sz %swpocc 11:31:58 4.0 30 0.0 0<表示結果>
runq-sz
実行可能だが実行待ちのプロセス数(vmstatのrと同等)
%runocc
実行キューが占有されていた時間の割合
swpq-sz
実行可能だがスワップアウトされたプロセス数
%swpocc
スワップ待ち行列が占有されている時間の割合
<監視ポイント>runq-sz / CPU数 > 2、かつ %runocc > 90 あるいは runq-sz > 10 の状態が継続する場合
CPU処理の負荷のため複数のプロセスがCPU待ちになっている可能性がある。
%runocc > 90、かつ runq-sz < 1 の状態が継続する場合
1つのプロセスがCPUを占有しCPU使用率が高くなっている可能性がある。
swpq-sz > 0 の状態が継続する場合
メモリ不足がシステム性能を悪化させている可能性がある。
-cオプション
システムコールの発行状況を確認する。
<実行例>% sar -c 5 1 11:39:57 scall/s sread/s swrit/s fork/s exec/s rchar/s wchar/s 11:40:02 1028 203 52 0.00 0.00 9613 8033<表示結果>
scall/s
システムコールの総数/秒
sread/s
readシステムコールの発行回数/秒
swrit/s
writeシステムコールの発行回数/秒
fork/s
fork(fork1、vfork含む)システムコールの発行回数/秒
exec/s
execシステムコールの発行回数/秒
rchar/s
readシステムコールが転送した文字数(バイト数)/秒
wchar/s
writeシステムコールが転送した文字数(バイト数)/秒
<監視ポイント>exec/s / fork/s > 3 以上の状態が続く場合
PATH環境変数に設定されているパスの順番がふさわしくない可能性がある。
rchar/s / sread/s < 8KB以上の状態が続く場合、あるいはwchar/s / swrit/s < 8KB以上の状態が続く場合
大きいサイズのファイルを小さい単位でアクセスするアプリケーションが動作している可能性がある。
-pオプション
ページイン動作状況を確認する。
<実行例>% sar -p 5 1 11:39:57 atch/s pgin/s ppgin/s pflt/s vflt/s slock/s 11:40:02 0.00 4.50 4.50 2.00 6.00 0.00<表示結果>
pgin/s
ページイン要求の平均数/秒
ppgin/s
ページインされた平均ページ数/秒
vflt/s
アドレス変換ページフォルト数/秒
<監視ポイント>vflt/s > 50(*)、かつsar -gコマンドのpgfree/s > 5の状態が続く場合
メモリ不足のため空きページを見つけるのに時間がかかっている。
(*) vflt/sが大きな値になる理由は以下の場合があるが、この場合はメモリ不足ではない。
ファイルシステムの内容が実メモリ上にキャッシュされ、ファイルシステムからのreadが多い場合(vflt/sと同時にpgin/s、ppgin/sの値も大きくなる)
プロセスの新規生成処理数が多い場合(vflt/sと同時にsar -cコマンドのfork/s、exec/sの値も大きくなる)
-gオプション
ページアウト、メモリ解放動作状況を確認する。
<実行例>% sar -g 5 1 11:46:43 pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf 11:46:48 0.00 0.00 0.00 0.00 0.00<表示結果>
pgfree/s
ページデーモンによって空きメモリ(sar -rのfreemem)に追加されたページ数
pgscan/s
ページデーモンによって走査されたn秒(*)あたりのページ数(vmstatのsrと同等)
%ufs_ipf
メモリの空きページからi-nodeを獲得した割合
(*) コマンド実行時に指定する計測間隔。
<監視ポイント>pgscan/s > 0 の状態が継続していると確認された場合
メモリが不足している可能性がある。
-rオプション
空きメモリ状況を確認する。
<実行例>% sar -r 5 1 11:46:43 freemem freeswap 11:46:48 588 830668<表示結果>
freemem
バーチャルメモリの空きページ数(単位:ページサイズ(*))
freeswap
ページスワップに使用可能なディスクブロック数(単位:512バイト/ブロック)
(*) ページサイズはカーネルアーキテクチャによって異なる。ページサイズはpagesizeコマンドにより確認することができる。
<監視ポイント>freememの値がlotsfree(*)の値を下回った場合
pageoutデーモンが起動されページアウトが開始される。
(*) lotsfreeはページング処理を開始するためのトリガーである(単位はページサイズ)。ページ数がlotsfreeのしきい値を下回るとpageoutデーモンがメモリスキャンを開始する。lotsfreeの値はmdbコマンドで確認できる。
# mdb -k > lotsfree/E lotsfree: lotsfree: 234 > $q
-dオプション
ディスク使用状況を確認する。
<実行例>
% sar -d 5 1
11:46:48 device %busy avque r+w/s blks/s avwait avserv
11:46:53 nfs1 0 0.0 0 0 0.0 0.0
sd0 0 0.0 0 0 0.0 0.0
sd0,a 0 0.0 0 0 0.0 0.0
sd0,b 0 0.0 0 0 0.0 0.0
sd0,c 0 0.0 0 0 0.0 0.0
sd3 0 0.0 0 0 0.0 0.0
<表示結果>
%busy
ディスクビジー率(転送要求サービスに費やした時間の割合) (iostatの%bと同等)
avque
実行を待っている要求の平均数
blks/s
デバイスに転送されたブロック数(単位:512バイト/ブロック)
avwait
転送要求がキュー上で待っていた平均時間/ミリ秒
avserv
転送要求がデバイスからサービスを受けた平均時間/ミリ秒
<監視ポイント>%busy > 60の状態が続く場合
ハードディスクなどのI/O装置の性能が不足しているためI/O処理でシステム性能が悪化している可能性がある。
同一コントローラ下のディスクのblks/sの合計 = コントローラ1秒あたりの転送量の3/4〜4/5に近い値が続く場合
ディスクコントローラの実行転送能力が低下している可能性がある。
RAIDを使用している場合%busyの値が高くてもハードディスクなどのI/O装置の性能が不十分であると特定ができないので、以下の項目についても確認する必要がある。複数の項目が該当する場合はディスクが問題となっている可能性がある。
avque > 1
avwait > avserv
avwait + avserv > 30
-bオプション
システムバッファの使用状況を確認する。
<実行例>% sar -b 5 1 19:10:28 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s 19:10:33 1 24 97 10 25 59 0 0<表示結果>
%rcache
システムバッファから読み込むことができた読み出し動作の割合(キャッシュヒット率)
%wcache
システムバッファへ書き込むことができた書き込み動作の割合(キャッシュヒット率)
<監視ポイント>%rcache < 90、かつ%wcache < 65の状態が続く場合
システムバッファが不足している可能性がある。
-vオプション
システムテーブルの使用状況を確認する。
<実行例>% sar -v 5 1 19:18:58 proc-sz ov inod-sz ov file-sz ov lock-sz 19:19:03 83/1882 0 5734/8316 0 601/601 0 0/0<表示結果>
proc-sz
プロセステーブルの使用数/割当数
ov
プロセステーブルのオーバーフロー発生回数
inod-sz
UFSファイルシステム用のi-nodeテーブルの使用数/割当数
ov
UFSファイルシステム用のi-nodeテーブルのオーバーフロー発生回数
file-sz
ファイルテーブルの使用数/割当数
ov
ファイルテーブルのオーバーフロー発生回数
lock-sz
カーネルで使用されている共用メモリレコードテーブルの使用数/割当数
<監視ポイント>各ov > 1の状態が続く場合
各テーブルのオーバーフローが発生している。
-aオプション
ファイルアクセスシステムルーチンの使用状況を確認する。
<実行例>% sar -a 5 1 19:18:58 iget/s namei/s dirbk/s 19:19:03 0 0 0<表示結果>
iget/s
i-node獲得ルーチンを呼び出した回数/秒
namei/s
ファイルシステムパス検索回数/秒
dirbk/s
UFSディレクトリブロック読み込み回数/秒
<監視ポイント>iget/s / namei/sの値が増加傾向にある状態が続く場合
ファイルアクセス時の負荷が高い可能性がある。
namei/s > 50、かつDNLCのヒット率(*) < 90の状態が続く場合
大量のi-nodeの獲得が行われている。
(*) DNLC(Directory Name Lookup Cache:ディレクトリ名検索キャッシュ)のヒット率の確認はvmstat -sコマンドで行う。
% vmstat -s : 20273707 total name lookups (cache hits 93%)
vmstatコマンド
vmstatコマンドはsarコマンドと同様にシステムのパフォーマンス状況を確認する。
Solaris以外にも広く実装されているコマンドである。
<実行例>% vmstat 5 1 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr dd f0 s0 -- in sy cs us sy id 0 0 0 472400 6536 5 23 38 10 12 0 4 4 0 0 0 363 751 238 5 2 93<表示結果>
procs : r
実行待ちのプロセス数(sar -qのrunq-szと同等)
page : sr
ページデーモンによって走査されたn秒(*)あたりのページ数(sar -gのpgscan/sと同等)
(*) コマンド実行時に指定する計測間隔。
cpu : us
ユーザ空間(プロセスの実行に費やされた時間)で使用されたCPUの時間の割合(sar -uの%usr、mpstatのusrと同等)
cpu : sy
カーネル空間(システムコールなどの処理時間)で使用されたCPUの時間の割合(sar -uの%sys、mpstatのsysと同等)
cpu : id
待ち状態にあるCPUの時間の割合(sar -uの%idle、mpstatの%idleと同等)
<監視ポイント>us + sy > 90、かつus < syの状態が継続する場合
メモリ不足がシステム性能を悪化させている可能性がある。
プロセスがシステムコールを多発してCPUに負荷がかかり、システム性能を悪化させている可能性がある。
us + sy > 90、かつus > syの状態が継続する場合
ユーザプロセスの異常動作によってCPUに負荷がかかり、システム性能を悪化させている可能性がある。
r / CPU数 > 2の状態が継続する場合
CPUが原因でシステム性能が悪化している可能性がある。
sr > 0の状態が 継続する場合
メモリ不足が問題でシステム性能が悪化している可能性がある。
mpstatコマンド
マルチプロセッサシステムの場合sarコマンドを使用すると全てのCPUの平均値が表示されるので、各CPUの使用状況を確認する場合にはmpstatを使用する。
シングルプロセッサシステムでは一つのプロセッサに関する情報を表示する。
<実行例>% mpstat 5 1 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 1 132 3 387 232 186 425 57 33 15 0 500 16 13 9 63 3 133 2 448 772 547 392 52 33 15 0 504 16 12 9 63<表示結果>
CPU
プロセッサID
smtx
mutex(相互排他ロック)の取得に失敗した回数/秒
usr
ユーザ空間(プロセスの実行に費やされた時間)で使用されたCPUの時間の割合(sar -uの%usr、vmstatのvsと同等)
sys
カーネル空間(システムコールなどの処理時間)で使用されたCPUの時間の割合(sar -uの%sys、vmstatのsyと同等)
wt
I/O処理によってCPU処理が待ち状態にあった時間の割合(sar -uの%wioと同等)
idl
待ち状態にあるCPUの時間の割合(sar -uの%idle、vmstatのidと同等)
<監視ポイント>usr + sys > 90、かつ usr < sysの状態が継続する場合
メモリ不足がシステム性能を悪化させている可能性がある。
プロセスがシステムコールを多発してCPUに負荷がかかり、システム性能を悪化させている可能性がある。
usr + sys > 90、かつ usr > sysの状態が継続する場合
ユーザプロセスの異常動作によってCPUに負荷がかかり、システム性能を悪化させている可能性がある。
wt > 10の状態が継続する場合
ハードディスクなどのI/O装置の性能が不足しているためI/O処理がシステム性能を悪化させている可能性がある。
smtx > 500、かつsys > 20の状態が継続する場合
システムコールの発行回数が多くmutex(相互排他ロック)の衝突がカーネルで発生しているためCPUが浪費されている可能性がある。
iostatコマンド
ディスクの使用状態を確認する。
<実行例>
% iostat -xtc 5 1
extended device statistics tty cpu
device r/s w/s kr/s kw/s wait actv svc_t %w %b tin tout us sy wt id
dad0 2.4 1.2 28.7 19.1 0.2 0.0 54.3 0 2 0 10 5 2 2 92
fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
<表示結果>
r/s
1秒あたりの読み込み回数
w/s
1秒あたりの書き込み回数
%w
サービス待ちの処理が存在していた時間の割合
%b
ディスクビジー率(転送要求サービスに費した時間の割合) (sar -dの%busyと同等)
<監視ポイント>%w > 5の状態が続く場合
SCSIバス負荷が高い可能性がある。
%b > 60の状態が続く場合
ハードディスクなどのI/O装置の性能が不足しているためI/O処理でシステム性能が悪化している可能性がある。
システムの稼働効率に影響を与えるカーネルパラメータについて
カーネルパラメータとは
カーネルパラメータはOSが動作をするにあたってカーネルが実メモリの実装などにより自動的に割り当てられる値を使用する環境(アプリケーションの起動等)にあわせて明示的に変更をさせることができる項目である。
中でもsarコマンドの結果から設定の見直しが必要だと確認できるカーネルパラメータについて紹介する。
カーネルパラメータの変更は容易に行うことができるが設定値の見積もりが正しく行われない場合は逆にシステムの性能の悪化を招く恐れがあるので十分注意した上で行うこと。
主なカーネルパラメータ
bufhwm ... システムバッファのサイズを調整する
sar -bコマンドで「%rcache < 90」かつ「%wcache < 65」の状態が継続して続くような場合はシステムバッファが不足している可能性がある。
この場合bufhwmパラメータの値を大きくし、システムの再起動をすることで性能が改善される可能性がある。
bufhwmのデフォルト値は物理メモリの2%で最大値は物理メモリの20%である。
ufs_ninode ... UFSファイルシステムのi-nodeキャッシュサイズを調整する
sar -gコマンドで「%ufs_ipf > 0」の状態が継続して続くような場合はカーネル上で管理できるinode数が足りなくなりディスクから毎回inodeを読み込む必要があることを示している。
この場合ufs_ninodeパラメータの値を大きくし、システムの再起動をすることで性能が改善される可能性がある。
ufs_ninodeのデフォルト値は「4 x (v.v_proc(*1) + maxusers(*2)) + 320」で、最大値は4G(1,024 x 1,024 x 1,024 x 4 - 1 = 4,294,967,295bytes)である。
(*1) v.v_procの値はsysdefコマンドで確認する。
# sysdef |grep v.v_proc 30000 maximum number of processes (v.v_proc)
(*2) maxusersの値の確認方法は後述する。
ncsize ... ディレクトリ読みとり用キャッシュサイズを調整する
sar -aコマンドの「namei/s > 50」かつ、vmstat -sコマンドの「DNLCヒット率 < 90」の状態が続く場合はディレクトリ名ルックアップキャッシュ(DNLC)が不足しており大量のinodeを読み込む必要があることを示している。
この場合ncsizeパラメータを大きくしシステムの再起動をすることで性能が改善される可能性がある。
ncsizeのデフォルト値は「4 x (v.v_proc + maxusers) + 320」で、最大値は4G(4,294,967,295bytes)である。
max_nprocs ... ユーザが起動できるプロセスの最大数を調整する
sar -vコマンドの「proc-sz」の項目で、システムで起動できるプロセス数と現在起動しているプロセス数を確認することができる。
起動しているプロセス数が上限に達してしまい終了できるプロセスも存在しない場合などは起動できるプロセス数の上限を増やす必要がある。
max_nprocsのデフォルト値は「10 + (16 x maxusers)」で、最大値は30000である。
尚、pidmaxパラメータを指定することにより最大値を999999まで上げることができる。
カーネルパラメータ変更方法
カーネルパラメータを変更する場合/etc/systemファイルに以下の記法で各パラメータを記述しシステムのリブートを行う。
set パラメータ = 値
デフォルト値のままの場合は/etc/systemファイルには記述されていない。
設定値の確認方法
設定値はsysdefコマンドにより確認する。
例)
# sysdef | grep bufhwm 146284544 maximum memory allowed in buffer cache (bufhwm)
その他のパラメータはmdbコマンドで確認する。
例)
# mdb -k > ufs_ninode/D ufs_ninode: ufs_ninode: 128512 > ncsize/D ncsize: ncsize: 128512 > max_nprocs/D max_nprocs: max_nprocs: 30000 > maxusers/D maxusers: maxusers: 2048 > $q
システムで発生した性能問題の調査から解決までの流れ
ここまではシステムの稼働状況を確認するためのコマンドやカーネルパラメータについて見てきたが、ここからはこれらコマンドを使用してシステムで発生した性能問題をどのように調査し解決していくのかについて説明する。
システムのスループットの低下やレスポンスの低下が一時的な現象であったり、トラブル原因への対策がカーネルパラメータの変更やプログラム実行スケジュールの変更などで改善できるのであればハードウェアの増強は必ずしも必要ない。
しかし、メモリの追加やCPUの増強といったハードウェアの性能向上が必要な場合もある。
その際システムの稼働効率を効果的に改善するためにはどのコンポーネント(パーツ)の増強が適切かという判断が重要である。
ここではシステムで発生した性能問題の調査から解決までのおおよその流れを説明する。
まずsarコマンドを使用してシステムの負荷状況を確認する。
# sar -u 1 5 02:35:52 %usr %sys %wio %idle 02:35:53 49 5 0 47 02:35:54 47 2 0 51 02:35:55 50 1 0 50 02:35:56 48 1 0 51 02:35:57 49 2 0 50 Average 49 2 0 49
CPU性能が不十分な場合
プロセスには実行状態、実行可能状態、待ち状態の3つの状態がある。
待ち状態は入出力の要求が行われ動作が完了すると実行可能状態となり、CPUの割り当てを待つ。
そしてCPU割り当てが行われると実行状態となりCPUを使用してプロセスが動作する。
このようにCPUはプロセスを動作する上で大変重要な役割を果たす。
1台のマシンでいくつものプロセスを実行した際、処理が遅いと感じることがある。
その原因としてCPUの搭載量と比べて実行プロセスの数が多すぎたり、1つのプロセスがCPUを占有して他のプロセスの実行を妨げたりしていることなどが考えられる。
sar -uの結果、「%usr + %sys > 90%」かつ「%usr > %sys」の場合はCPUの使用率が高くユーザプロセスが原因の可能性がある。 ユーザプロセスを確認するためにsar -qコマンドで原因を調査する。
# sar -q 1 5 02:34:43 runq-sz %runocc swpq-sz %swpocc 02:34:44 0.0 0 0.0 0 02:34:45 0.0 0 0.0 0 02:34:46 0.0 0 0.0 0 02:34:47 0.0 0 0.0 0 02:34:48 0.0 0 0.0 0 Average 0.0 0 0.0 0
「%runocc > 90」かつ「runq-sz / CPU数 > 2」、あるいは「runq-sz > 10」の場合は複数のプロセスが原因でCPU異常を起こしている可能性がある。
逆に「%runocc > 90」かつ「runq-sz < 1」の場合は1つのプロセスが原因でCPU異常を起こしている可能性がある。
双方ともpsコマンドにより問題となっているプロセスを特定する必要があるが、後者の場合は他のプロセスへの影響がなければそのままの状態でも問題ない。また、前者の場合はpriocntlコマンド(*)を使用してバッチ処理の優先度を変更するなどの検討を行う必要があるが、これらの対処を行っても改善が見られない場合は他の改善策としてCPUの増設を検討する。
「%usr + %sys > 90%」かつ「%usr < %sys」の場合はCPU負荷、もしくはメモリ不足の可能性がある。
vmstatコマンドでI/Oの割り込み頻度を調べる。
# vmstat 1 5 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr m0 m1 m1 m1 in sy cs us sy id 0 0 0 270096 75248 9 35 0 0 0 0 0 0 0 0 0 130 216 119 1 1 98 0 0 0 218880 41216 0 6 0 0 0 0 0 0 0 0 0 128 37 112 0 0 99 0 0 0 218880 41216 0 0 0 0 0 0 0 0 0 0 0 131 392 115 0 0 99 0 0 0 218880 41216 0 0 0 0 0 0 0 0 0 0 0 130 354 125 0 3 97 0 0 0 218880 41216 0 0 0 0 0 0 0 0 0 0 0 124 32 120 0 0 99
「in > 200」の場合はハードウェアの問題が発生している可能性があるためI/Oコネクタの接続状態を確認する。
「in < 200」の場合はシステムコールの発行回数が多発している可能性があるため更にsar -cコマンドでシステムコールの発行回数を確認する。
# sar -c 1 5 02:53:20 scall/s sread/s swrit/s fork/s exec/s rchar/s wchar/s 02:53:21 291 27 29 0.00 0.00 6201 6331 02:53:22 633 25 26 0.00 0.00 6130 6241 02:53:23 259 25 26 0.00 0.00 6069 6179 02:53:24 264 25 26 0.00 0.00 6130 6241 02:53:25 262 25 26 0.00 0.00 6130 6241 Average 342 25 26 0.00 0.00 6132 6247
また、メモリ不足が原因でpageoutデーモンのカーネル空間での頻繁な動作が起こりCPU使用率を上げてしまう可能性があるため、sar -gコマンドでメモリ不足になっていないか確認する必要もある。
# sar -g 1 5 02:54:57 pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf 02:54:58 0.00 0.00 0.00 0.00 0.00 02:54:59 0.00 0.00 0.00 0.00 0.00 02:55:00 0.00 0.00 0.00 0.00 0.00 02:55:01 0.00 0.00 0.00 0.00 0.00 02:55:02 0.00 0.00 0.00 0.00 0.00 Average 0.00 0.00 0.00 0.00 0.00
これらの確認に加え、発生したシステム異常が一時的なものであるか慢性的なものであるかについても確認する必要がある。
一時的なものであればそのままシステムの監視を続けるが、慢性的なものであればユーザプロセスの確認や実行プロセス数に合わせたCPUの追加を検討する必要がある。
一般的にはsar -qコマンドのrunq-szをCPU数で割った結果が2以下になるようにCPUを追加すればよいと言われている。
(*) priocntlコマンドは指定したプロセスのスケジューリングを行う。プロセスがどのようなスケジューリングをされて動作しているかはps -elcコマンドのCLS(クラス)とPRI(優先順位)の項目を確認する。
以下の場合はsampleプロセスはIA(インタラクティブクラス)、優先度20で動作している。
# ps -elc | grep sample F S UID PID PPID CLS PRI ADDR SZ WCHAN TTY TIME CMD 8 S 1679 20859 26567 IA 20 ? 3310 ? ?? 4958:05 sample
これをIAよりも優先度の低いTS(タイムシェアリングクラス)に変更する方法は以下になる。
# priocntl -s -c TS -i pid 20859
メモリ容量が不十分な場合
プロセスのメモリ要求が使用できる物理メモリ量を超えるとシステムはメモリ不足の状態に陥りpageoutデーモンの動作が始まる。
pageoutデーモンの動作が始まるのはsar -rコマンドのfreememがlotsfree(*)値を下回った時である。
# sar -r 1 5 03:01:39 freemem freeswap 03:01:40 754845 26433952 03:01:41 747353 26172230 03:01:42 754803 26433952 03:01:43 754779 26433952 03:01:44 754761 26433952 Average 753296 26381188
lotsfree値を下回るとpageoutデーモンは物理メモリをスキャンして最近使用されていないページを探し出し、そのページをスワップデバイスにページアウトさせて物理メモリを解放する(ページング)。
pageoutデーモンによって行われるスキャンの速度は利用可能なページ量の減少に従い頻繁に動作するようになる。
そのためCPU使用率が上昇しシステム性能は著しく低下する。このスキャン状態はsar -gで確認する。
# sar -g 1 5 03:02:37 pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf 03:02:38 0.00 0.00 0.00 0.00 0.00 03:02:39 0.00 0.00 0.00 0.00 0.00 03:02:40 0.00 0.00 0.00 0.00 0.00 03:02:41 0.00 0.00 0.00 0.00 0.00 03:02:42 0.00 0.00 0.00 0.00 0.00 Average 0.00 0.00 0.00 0.00 0.00
「pgscan/s > 0」の場合はシステムがメモリ不足であると判断することができる。
また、システムの仮想メモリが足りなければプロセスの生成ができなくなるほか、アプリケーションがメモリを確保することができないために異常動作(異常終了)を起こす可能性がある。
psコマンドを定期的に実行し、多くのメモリを使用しているプロセスが存在していないか、またはswapファイルと他のファイルとのI/O競合が発生していないかなどを確認する。
仮想メモリの使用量についてはswap -sコマンド、sar -rコマンドで確認ができる。
# swap -s total: 30200k bytes allocated + 17856k reserved = 48056k used, 13216920k available # sar -r 1 5 03:04:34 freemem freeswap 03:04:35 754857 26433152 03:04:36 754857 26433152 03:04:37 754857 26433152 03:04:38 754857 26433152 03:04:39 747383 26171438 Average 753350 26380390
swap -sコマンドについてはavailableの項目が、sar -rについてはfreeswapの項目が仮想メモリの空き容量になる。
仮想メモリが足りない場合はswapデバイスを追加して容量を増やすことになるが、実際に増やさなければならない容量は実行プロセス数やプログラミングの方法などに依存するため、日々の運用の中で決定する必要がある。
swapデバイスの追加についてはパーティションを切り直すほかにswap -aコマンドで他の空いているデバイスをswapデバイスとして追加することができる。
(*) lotsfreeはページング処理を開始するためのトリガーである。ページ数がlotsfreeのしきい値を下回るとpageoutデーモンがメモリスキャンを開始する。lotsfreeの値はmdbコマンドで確認できる。
# mdb -k > lotsfree/E lotsfree: lotsfree: 13775 > $q
ディスク装置の性能が不十分な場合
ディスクはCPUやメモリに比べるとアクセス性能が遅いため、レスポンスの悪化を起こしやすい資源である。
# sar -u 1 5 02:35:52 %usr %sys %wio %idle 02:35:53 49 5 0 47 02:35:54 47 2 0 51 02:35:55 50 1 0 50 02:35:56 48 1 0 51 02:35:57 49 2 0 50 Average 49 2 0 49
sar -uコマンドの結果、「%wio > 10」の場合はハードディスクなどのI/O装置の性能が不足している可能性がある。
ディスク資源にはディスク装置、ディスク資源をコントロールするコントローラと2つの要素がある。
通常1つのディスクコントローラの下には複数のディスク装置やその他の入出力装置が接続されている。
接続される装置の台数が多くなると個々の装置の負荷はそれほど高くなくてもディスクコントローラのデータ転送が悪化する場合がある。
ディスク資源に問題がある場合、複数のプロセスによる同一ディスクの競合が原因となっている可能性がある。
ディスクの性能に悪影響を及ぼさない使用率はsar -dコマンドの%busyが60%以下だと言われており、60%を越えるとディスクアクセス時間は通常時の2〜3倍以上に低下してしまう。
もし複数のプロセスが同一ディスクに対してアクセスしている場合は資源の分散をするなどしてアクセス負荷についても分散させるのが良いだろう。
# sar -d 1 5
03:14:58 device %busy avque r+w/s blks/s avwait avserv
03:14:59 md0 95 4.9 220 46643 5.0 17.2
md1 0 0.0 0 0 0.0 0.0
md10 88 2.9 217 45874 0.0 13.1
md11 0 0.0 0 0 0.0 0.0
md20 92 3.0 220 46884 0.0 13.6
md21 0 0.0 0 0 0.0 0.0
nfs1 0 0.0 0 0 0.0 0.0
sd0 93 3.4 228 45885 0.0 15.0
sd0,a 88 2.8 217 45874 0.0 13.1
sd0,b 0 0.0 0 0 0.0 0.0
sd0,c 0 0.0 0 0 0.0 0.0
sd0,h 58 0.6 11 11 0.0 52.5
sd1 99 3.8 233 46898 0.0 16.5
sd1,a 92 3.0 220 46886 0.0 13.6
sd1,b 0 0.0 0 0 0.0 0.0
sd1,c 0 0.0 0 0 0.0 0.0
sd1,h 85 0.8 12 12 0.0 70.4
sd30 0 0.0 0 0 0.0 0.0
:
Average md0 98 5.3 204 44219 5.2 20.6
md1 0 0.0 0 0 0.0 0.0
md10 89 3.1 203 43963 0.0 15.5
md11 0 0.0 0 0 0.0 0.0
md20 89 3.0 205 44390 0.0 14.4
md21 0 0.0 0 0 0.0 0.0
nfs1 0 0.0 0 0 0.0 0.0
sd0 97 3.9 218 43977 0.0 18.0
sd0,a 89 3.1 204 43963 0.0 15.4
sd0,b 0 0.0 0 0 0.0 0.0
sd0,c 0 0.0 0 0 0.0 0.0
sd0,h 77 0.8 14 14 0.0 55.2
sd1 99 3.8 219 44405 0.0 17.2
sd1,a 89 3.0 205 44391 0.0 14.4
sd1,b 0 0.0 0 0 0.0 0.0
sd1,c 0 0.0 0 0 0.0 0.0
sd1,h 80 0.8 14 14 0.0 57.4
sd30 0 0.0 0 0 0.0 0.0
blks/sが使用しているコントローラの1秒あたりの転送量(*)の3/4〜4/5に近い場合、コントローラが問題となっている可能性がある。
コントローラの増設やコントローラの再配置(コントローラが複数あると負荷が不均等になっている場合があるため)を行う。
(*) コントローラの1秒あたりの転送量はblks/s(1blks:0.5KB)の合計になる。
また、sar -bコマンドの結果「%rcache < 90」または「%wcache < 65」の場合はシステムバッファが不足しているのでカーネルパラメータであるbufhwmを拡張することによりアクセス性能の改善を行うことができる可能性がある。
# sar -b 1 5 03:19:35 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s 03:19:36 0 56 100 0 36 100 2 0 03:19:37 0 76 100 0 48 100 0 0 03:19:38 0 57 100 0 36 100 0 0 03:19:39 0 74 100 0 48 100 0 0 03:19:40 0 76 100 0 48 100 0 0 Average 0 68 100 0 43 100 0 0
具体的な解析例
では実際にシステム性能になんらかの問題が起こった場合の解析の流れをコマンドの実行結果もふまえながら具体的に紹介していく(スクリプト等はSolaris8のものを使用)。
システム性能はいつ悪化するかわからない。
そのような場合に備えてsarコマンドをcronのジョブとして定期的に実行させることで毎日の性能データが/var/adm/saディレクトリ配下に作成される。
cronで採取されたデータをsarコマンドで調査する場合、「計測間隔」と「計測回数」を指定する必要はなく、自動的に採取されたデータの値が表示される。
尚、本章での解析例は5分毎にデータが採取されていることを前提としている。
sarコマンドをcronジョブとして実行させる方法
/etc/rc2.d/S21perfファイルの該当部分のコメントを外し、システム起動時に性能情報の採取を開始するように設定する。
20 # if [ -z "$_INIT_RUN_LEVEL" ]; then
21 # set -- `/usr/bin/who -r`
22 # _INIT_RUN_LEVEL="$7"
23 # _INIT_RUN_NPREV="$8"
24 # _INIT_PREV_LEVEL="$9"
25 # fi
26 #
27 # if [ $_INIT_RUN_LEVEL -ge 2 -a $_INIT_RUN_LEVEL -le 4 -a \
28 # $_INIT_RUN_NPREV -eq 0 -a \( $_INIT_PREV_LEVEL = 1 -o \
29 # $_INIT_PREV_LEVEL = S \) ]; then
30 #
31 # /usr/bin/su sys -c "/usr/lib/sa/sadc /var/adm/sa/sa`date +%d`"
32 # fi
sysユーザのcron設定の該当部分のコメントを外し、定期的に性能データを収集するように設定する。
# crontab -e sys 0 * * * 0-6 /usr/lib/sa/sa1 20,40 8-17 * * 1-5 /usr/lib/sa/sa1 5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A
1行目 : 1時間おきに性能データを収集
2行目 : 月〜金曜日の8:00〜17:00は20分と40分に性能データを収集
3行目 : 月〜金曜日の18:05に8:00〜18:01までのシステム状況をレポート
解析例1
解析
システムの動作状態をsar -uコマンドで確認する。
% sar -u -s 14:25 -e 14:50 14:25:00 %usr %sys %wio %idle 14:30:00 2 5 71 22 14:35:00 5 6 88 0 14:40:00 2 4 91 2 14:45:00 1 4 95 0 14:50:00 3 6 91 0
→ %wioの値が高いためI/O処理の多発によりディスクに負荷がかかっている可能性がある。
sar -dコマンドでディスクアクセスの確認を行う。
% sar -d -s 14:25 -e 14:50
14:25:00 device %busy avque r+w/s blks/s avwait avserv
14:30:00 dad0 72 0.7 113 617 0.0 6.5
dad0,a 0 0.0 0 0 0.0 0.0
dad0,b 0 0.0 0 3 0.0 13.4
dad0,c 0 0.0 0 0 0.0 0.0
dad0,d 0 0.0 1 11 0.0 3.2
dad0,e 72 0.7 112 602 0.0 6.5
dad0,h 0 0.0 0 0 0.0 0.0
:
14:50:00 dad0 89 0.9 129 1121 0.0 7.2
dad0,a 0 0.0 0 3 0.0 18.3
dad0,b 0 0.0 0 3 0.0 14.6
dad0,c 0 0.0 0 0 0.0 0.0
dad0,d 0 0.0 0 0 0.0 0.0
dad0,e 89 0.9 129 1114 0.0 7.2
dad0,h 0 0.0 0 0 0.0 0.0
→ dad0,eの%busyが60を越えているためdad0,eデバイスの負荷が高いことが確認できる。
iostatコマンドでディスクアクセスの確認を行う。
% iostat -xtc 5 30 device r/s w/s kr/s kw/s wait actv svc_t %w %b tin tout us sy wt id dad0 150.2 0.2 259.4 1.6 0.0 0.9 6.3 0 72 0 181 5 6 88 0 fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
→ 負荷が高いdad0デバイスに注目する。ビジー率は高いが%wの値が5以下のためSCSIバスの負荷はない。
負荷がかかっているdad0,eデバイスとディスクの対応付けを行う。
(/dev/dskからdad0,eに該当するディスクを確認する)
% ls -l /dev/dsk lrwxrwxrwx 1 root root 38 9月 20日 2001年 c0t0d0s1 -> ../../devices/pci@1f,0/ide@d/dad@0,0:c lrwxrwxrwx 1 root root 29 9月 20日 2001年 c0t0d0s2 -> ../../devices/pci@1f,0/ide@d/dad@0,0:d lrwxrwxrwx 1 root root 38 9月 20日 2001年 c0t0d0s3 -> ../../devices/pci@1f,0/ide@d/dad@0,0:e
→ 上記からdad0,eはc0t0d0s3であることがわかる。
(c0t0d0s3をdf -kコマンドの結果から判断する)
% df -k ファイルシステム kbytes 使用済み 使用可能 capacity マウント先 /dev/dsk/c0t0d0s0 1760958 350133 1357997 21% / /dev/dsk/c0t0d0s3 4127894 1139940 2946676 28% /export /proc 0 0 0 0% /proc
→ 上記の結果からc0t0d0s3は/exportだということがわかる。
I/Oが高いためキャッシュヒット率の確認を行う。
% sar -b -s 14:25 -e 14:50 14:25:00 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s 14:30:00 25 171 86 1 2 50 0 0 14:35:00 23 169 80 1 2 48 0 0 14:40:00 21 180 83 1 2 60 0 0 14:45:00 21 183 85 1 2 62 0 0 14:50:00 23 165 78 1 2 48 0 0
→ %rcache < 90、かつ%wcache < 65のためシステムバッファが不足していることがわかる。
原因
%wioの値が高いのは/exportに対してのI/O処理が多発しておりディスクに負荷がかかっているためと判断できる。
またsar -bコマンドの結果から、システムバッファが不足していることがわかる。
対策
まず、高負荷の状態にあった時間/exportに対して頻繁にI/O処理を行っていたプロセスの処理を確認する。
/export以外にI/O処理が分散可能な場合はプロセスの見直しを行うことでディスクアクセスの負荷分散が可能である。
しかし/exportのみのアクセスになる場合はシステムバッファが不足しているため/etc/systemファイルに「set bufhwm = 値」を記述してシステムバッファを増やしI/O処理で使用するバッファを増やす。
結果
プロセスのI/O処理を分散させる対策をとった場合はsar -dコマンドの%busyを確認し、他のディスクにアクセスが行われディスクアクセスの負荷分散がされているか、%busyの値が60%以下になっているかを確認する。
以下はディスクアクセスの負荷分散を行った後にdad0,eの値を確認した結果である。
% sar -d -s 15:25 -e 16:00
15:25:00 device %busy avque r+w/s blks/s avwait avserv
15:30:00 dad0 53 3.5 41 9483 61.1 24.9
dad0,a 1 0.0 0 1 0.0 22.4
dad0,b 1 0.0 0 5 0.0 21.2
dad0,c 0 0.0 0 0 0.0 0.0
dad0,d 0 0.0 0 5 0.0 2.6
dad0,e 53 3.5 41 9472 61.1 24.9
dad0,h 0 0.0 0 0 0.0 0.0
:
16:00:00 dad0 55 3.6 43 9966 59.5 22.3
dad0,a 0 0.0 0 0 0.0 0.0
dad0,b 1 0.1 0 5 0.0 31.7
dad0,c 0 0.0 0 0 0.0 0.0
dad0,d 0 0.0 0 0 0.0 0.0
dad0,e 55 3.5 43 9961 59.5 22.3
dad0,h 0 0.0 0 0 0.0 0.0
また以下はbufhwmを設定しシステムバッファを増やした際、処理時間を比較した結果である。
bufhwmの設定前と設定後で処理時間が早くなっていることが確認できる。
(設定前)
# time sample real 1:24.7 user 0.4 sys 4.5
(設定後)
# time sample real 56.4 user 0.5 sys 4.3
解析例2
解析
システムの動作状態をsar -uコマンドで確認する。
% sar -u -s 15:05 -e 15:30 15:05:00 %usr %sys %wio %idle 15:10:00 96 4 0 0 15:15:00 96 4 0 0 15:20:00 96 4 0 0 15:25:00 95 5 0 0 15:30:00 94 6 0 0
→ %usrがCPU使用率の大部分を占めており、ユーザプロセスが原因となっている可能性がある。
システムコールの発行状況を確認する。
% sar -q -s 15:05 -e 15:30 15:05:00 runq-sz %runocc swpq-sz %swpocc 15:10:00 0.6 91 15:15:00 0.7 96 15:20:00 0.7 97 15:25:00 0.7 96 15:30:00 0.7 96
→ runq-sz < 1、かつ %runocc > 90 の状態が続いているため1つのプロセスがCPUを占有していることがわかる。
原因となるプロセスが何かを見つける。
% prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 20859 user2 26M 20M run 59 0 46:49.23 99% sample/1 3359 user1 2536K 1504K cpu0 58 0 0:00.00 0.2% test-comm/1
→ sampleプロセスが99%のCPUを使用している。
原因
CPU使用率が高かったのはsampleプロセスが原因であると判断できる。
対策
プログラムの作りによる異常動作ではない場合で、あるプロセスが原因となり他のプロセスの動作に影響を与えているようであれば、プロセスの優先度を下げたり先に実行させたいプロセスの優先度を上げることで対処が可能である。
以下はsampleプロセスの優先度を下げる方法である。
% ps -elc | grep sample F S UID PID PPID CLS PRI ADDR SZ WCHAN TTY TIME CMD 8 S 1679 20859 26567 RT 100 ? 3310 ? ?? 24958:05 sample
現在sampleプロセスの優先度はRT(リアルタイムクラス)で動作している。
これを優先度の低いTS(タイムシェアリングクラス)に変更する。
# priocntl -s -c TS -i pid 20859 % ps -elc |grep sample F S UID PID PPID CLS PRI ADDR SZ WCHAN TTY TIME CMD 8 S 1679 20859 26567 TS 59 ? 3310 ? ?? 24958:05 sample
sampleプロセスの優先度を下げることでsampleプロセスよりも優先度が高いプロセスの実行が優先して行われるようになる。
また、sampleプロセスが99%ものCPUを使用しておりシステムパフォーマンスに影響を与えているようであればプロセスをkillすべきである。
ただし、killで対処する場合は対象プロセスがCPUの大部分を占めプログラムの動作上異常と判断した場合のみ実行するなど、実行の際は十分注意すること。
結果
対策としてプロセスの優先順位を下げた場合は先に処理させたいプロセスの実行が行われる。
またsampleプロセス自体の問題と判断しkillした場合はCPU使用率は正常値に戻る。
% sar -u -s 16:05 -e 16:30 16:05:00 %usr %sys %wio %idle 16:10:00 93 2 0 5 16:15:00 18 1 0 81 16:20:00 9 2 0 89 16:25:00 0 0 0 100 16:30:00 0 0 0 100
また同時にCPU実行待ちのプロセスがなくなる。
% sar -q -s 16:05 -e 16:30 16:05:00 runq-sz %runocc swpq-sz %swpocc 16:10:00 0.7 96 16:15:00 16:20:00 16:25:00 16:30:00
CPU使用率が高くても特にCPUを圧迫しているプロセスが存在しない場合はpriocntlコマンドにより優先させて実行したいプロセスの優先順位を上げる。
解析例3
解析
システムの動作状態をsar -uコマンドで確認する。
% sar -u -s 18:20 -e 18:45 18:20:00 %usr %sys %wio %idle 18:25:00 31 69 0 0 18:30:00 37 63 0 0 18:35:00 55 45 0 0 18:40:00 35 65 0 0 18:45:00 32 62 0 6
→ %sysの値が極端に高いことがわかる。CPU負荷の他にメモリ不足に陥っている可能性がある。
sar -qにてスワップアウトされたプロセス数を確認する。
% sar -q -s 18:20 -e 18:45 18:20:00 runq-sz %runocc swpq-sz %swpocc 18:25:00 1.2 100 48.0 100 18:30:00 1.0 100 48.0 100 18:35:00 1.2 100 48.0 100 18:40:00 1.0 100 48.0 100 18:45:00 1.0 100 48.0 100
→ runq-szの値からCPU待ちのプロセスがあること、swpq-szの値からスワップアウトしてしまったプロセスが多発していることがわかる。プロセスがスワップアウトする場合、仮想メモリ不足が考えられる。
(参考) ページングとスワッピング
新たにプロセスが起動する際、システムの仮想メモリに空きがなければ仮想メモリを使用している必要がないと判断されたプロセス(一度だけ実行されて後はスリープ状態にあるなど)が仮想メモリに空きを作るためにページ単位でスワップデバイスに追い出され、その部分に当該プロセス用のメモリ領域が割り当てられる。
これをページングという。
さらに、ページ単位での追い出しでも仮想メモリの空き容量が足りない場合はプロセス単位でスワップデバイスに追い出され、ページングと同様にその部分に当該プロセス用のメモリ領域が割り当てられる。
これをスワッピングという。
sar -gにてページスキャンの状態を確認する。
% sar -g -s 18:20 -e 18:45 18:20:00 pgout/s ppgout/s pgfree/s pgscan/s %ufs_ipf 18:25:00 0.00 0.00 0.00 0.00 0.00 18:30:00 0.25 0.25 0.25 0.00 0.00 18:35:00 91.11 760.74 1055.80 7568.64 0.00 18:40:00 185.95 905.58 1070.91 7647.93 0.00 18:45:00 141.53 798.40 812.88 6346.71 0.00
→ pgscan/sの結果から18:35:00から18:45:00までページスキャンが頻繁に走り、空きメモリを探している状態であり一定の時刻だけメモリ不足になっていたことがわかる。また、ページスキャンが頻繁に走る時はpageoutデーモン(*)のCPU使用率が上がっていく。
(*) pageoutデーモンはカーネル空間で動作する。メモリの内容をディスクに書き込み、開放できるメモリを探す。また、空きメモリの量が少なくなると頻繁に動作するようになるのでCPU使用率が高くなる。同時にページング、スワッピングも多発するのでディスクへの負荷も高くなる。
sar -rにて空きメモリの量を確認する。
% sar -r -s 18:20 -e 18:45 18:20:00 freemem freeswap 18:25:00 6100 874104 18:30:00 6180 875292 18:35:00 57 206538 18:40:00 59 205894 18:45:00 196 210687
→ freememの結果で18:35:00から多くのメモリが消費されていることがわかる。
どのプロセスがメモリを多く使用しているか確認する。
% prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 522 user1 411M 85M sleep 44 0 0:00.03 2.6% sample/1 478 user1 2424K 960K sleep 58 0 0:00.00 0.1% test.sh/1 67 root 2328K 1320K sleep 31 0 0:00.00 0.0% picld/8
→ SIZEの結果から、sampleプロセスが仮想記憶領域を411MB使用していることが確認できる。
プロセス情報の確認方法
解析ではプロセスの確認をおこなうためにps/prstatコマンドを実行しているが、この場合は現在起動中のプロセス情報が表示されるため後でどのプロセスがメモリやCPUを消費していたのかを確認することができない。
そのため後からプロセスを特定するには事前にアカウンティングの設定が必要になる。
アカウンティングの設定を行うと、いつ、誰が、どのプロセスを起動し、そのプロセスがどれだけメモリやCPUを使用したかを確認することができる。
原因
sampleプロセスが多くのメモリを使用していた。
sar -qコマンドのswpq-szの値からスワップアウトされたプロセスも多数あり、sar -gマンドのpgscan/sの値からメモリ不足に陥っている。
このことからsar -uコマンドの%sysの値が高いのは他にCPUを多く使用しているプロセスが存在するのではなく、メモリ不足が原因でCPUが多く使われていることがわかる。
対策
メモリが一番使われている時間では他のプロセスが使用できるメモリの残りは僅かである。
この時間帯に他のプロセスを動作させる必要がある場合はswapデバイスを足して使用できるメモリを増やす。
しかし、swapデバイスを追加してもsampleプロセスが多くのメモリを消費するのでシステムの仮想メモリは不足する。
そのためpageoutデーモンによるスキャンが頻繁に行われるためpageoutデーモンのCPU使用率は変わらずシステムのCPU使用率も高いまま変わらない。
pageoutデーモンのスキャン動作を押さえる場合はメモリの増設を検討する必要がある。
結果
swapデバイスを追加した場合は使用できるメモリが増える。
sampleプロセスが多くのメモリを消費しても追加した分のメモリが残っているため他のプロセスもメモリを使用することができる。
また、システムにメモリを増設した場合はpageoutデーモンのスキャン頻度が減りシステムのCPU使用率も低くなる。
おわりに
システムの性能を向上させるためには一部のデータから判断するのではなく、システム全体のパフォーマンス状態を把握し問題となる部分を見つけだす必要がある。
sar、iostat、prstatコマンド等のコマンドを駆使し、より効率的にパフォーマンスに関する問題を解決していきたい。