Solaris 資料一覧

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コマンド等のコマンドを駆使し、より効率的にパフォーマンスに関する問題を解決していきたい。