まとめ

表1に、各資源のまとめを示します。

表１．まとめ

資源種別 No 問題とする指標 対応のポイント 対象コマンド・パラメタ等
CPU 1 sar -u %usr > 70%
sar -u %usrと%sysの比率が
3対1　(1対1が理想)
sar -q runq-szがCPU数+2以上
truss出力の内訳		 メモリ操作、走査、計算方法の変更。単に%usrが高い値を示している場合は大きな計算を行っているか、またはテーブルハンドリング、文字列比較等を行っているケースが多いです。文字列ハンドリングはstring(3C)でなく、memory(3C)を使うようにします。レジスタを使用した計算の場合はメモリタッチを伴わないことが多いため、ページフォルトの発生は少ないです。テーブル、特に大域のテーブルをハンドリングする場合は大量のページフォルトを伴うことがあります。単なる計算の場合のCPU使用は標準のTSディスパッチャテーブルによって他のプロセス(スレッド)に迷惑はかかりません。 通常、プログラムで使用されるアルゴリズムを見直すことが一般的です。TSディスパッチャテーブルをチューニングする方法もありますが、この措置は最終手段で一般的ではありません。dispadmin(1M)コマンドのテーブル読み込み、およびセット。
2 sar -c scall/s対sread/s、又は
swrit/sの比率
sar -c scall/s対fork/sとexec/sの比率
sar -u %sys > 70%
sar -u %usrと%sysの比率が
3対1　(1対1が理想)
sar -w pswch/sの量
truss出力の内訳		 冗長なシステムコールの削減。入出力命令の工夫。ディスクのランダムアクセスに使用されるlseek(2)、write(2)、read(2)は、位置決め、書き込み/読み込みの2回のシステムコールを発行することになります。このかわりにpread(2)、pwrite(2)を使用すると1回のシステムコールで済みます。listen(3SOCKET)はpoll(2)、select(3C)を使用する。例えば10秒に1個のトランザクションがあり、クライアントが10台とします。到着率は順次到着の場合1件/1秒です。TPモニターのような待機型のリスナーで最大1秒に10件のトランザクションが発生すると仮定します。このような場合、トランザクションの処理時間は無視するとして、100ミリ秒でリッスンすると良いことになります。これに対して、1ミリ秒でリッスンするのは無駄です。他にプロセス間通信のメッセージキューやセマフォの待ち等も同様です。このようなロジックの場合、poll(2)、select(3C)を利用したイベントドリブン型リスナーにすることで%sysの割り合いを下げるのに効果的です。 通常、プログラムのロジックを見直すことが一般的です。
3 sar -u %sys > 70%
sar -u %usr+%sys > 95%
sar -c scall/sとsar -m sema/smsg/sの比率、量
truss出力の内訳		 プロセス間通信関連パラメタのチューニング。プログラムによってセマフォIDの獲得、ロック待ちでスピンウェイト処理に入ってしまい、%usrを押し上げていることがあります。プロセス間通信関連パラメタのチューニングは確実に行って下さい。 /etc/systemファイル
set msgsys:msginfo_xxx=nnn
set semsys:seminfo_xxx=nnn
set shmsys:shminfo_xxx=nnn
4 mpstat smtx > 500
vmstat interrupt
truss出力の内訳
kgmon/gprof出力の内訳
prex出力の内訳		 プロセッサバインドでの振舞い。インタラプト数の確認。mutexロックがCPU間の競合でラッシュしているかどうかを確認するために、対象となるプロセスをpbind(1M)やprocessor_bind(2)で特定のCPUにバインドして振る舞いを見る方法があります。CPUをバインドしたままクライアント数やトランザクションを増加した時、性能指標の値や応答時間が線形に伸びるのか、あるいは変化しないのか、又は予期せぬ結果になるのかを確認することで対策を検討することが出来ます。複数CPUが構成されているシステムにおいて、psradm(1M)でCPU数を動的に増減(ディスエブル、イネーブル)して振る舞いを確認する方法があります。マルチスレッドプログラムの問題も見逃せません。インタラプトは予想される割り込み数かどうかを確認する必要があります。ハードウェア障害によるインタラプト数の増加もあり得ます。 直接のチューニングパラメタはありません。通常、プログラムのロジック、アルゴリズムを見直すことが一般的です。
ディスク
入出力		 1 sar -d %busy > 70%
sar -d avwait > 50ms
iostat -x svc_t > 50ms
sar -d avserv > 50ms
iostat serv > 50ms		 オンライン処理と並行してバックアップ等の巨大なバッチジョブを実行すると高負荷になります。起こるべくして起きている高負荷と予期せぬ高負荷を切り分ける必要があります。業務時間帯を分ける。ファイルが同一のディスクに集中している場合は他のディスクに分散します。LVMやDiskSuite等でストライピングする方法もあります。ディスクの型によって、ZBR(Zone Bit Recording)の場合頻繁にアクセスするファイルはディスクの内側(即ち最初の方)に配置するとアクセスは早くなります。UFSをVxFSファイルシステムに変更する方法もあります。また、rawモードを使用すると効果的な場合があります。メモリに余裕があり、テンポラリファイルのように使用する場合はメモリファイルにすると高速にアクセスすることが出来ます。 /etc/systemファイル
set ufs:ufs_HW=nnn
set ufs:ufs_LW=nnn
2 sar -a igets、namei/s、dirblk/s
sar -v inode
netstat -kの maxsize<maxsize_reached		 一旦メモリ上のiノードキャッシュに張り付いた後はiノードのためのディスクアクセスが無いことが理想です。iノードキャッシュ数をチューニングします。アプリケーション側の配慮として、ファイル名やディレクトリ名の長さを30文字以内に抑えると良いです。 /etc/systemファイル
set ncsize=nnnnn
set ufs_ninode=nnnnn
set vxio:vxfs_nonode=nnnnn
3 iostat -d kps、tps
sar -c rchar/s、wchar/sが
sread/s、swrit/sに比べて少ない		 転送キロバイト数対転送数が接近しているとブロック化係数が小さいことを示しています。アプリケーションの定義を検査して下さい。ORACLE等のデータベースではDBブロックサイズを確認します。また、sar -cのscall/s、sread/s、swrit/sとのバランスを確認します。1度の入出力命令でより多くのデータを入出力すると効果的です(注意：あまり大き過ぎるとメモリに対する悪影響が出てきます)。 ORACLEのdb_block_size、プログラムにおけるread/write命令の引数に指定されたブロックサイズ等。
4 sar -b %rcache < 90%
sar -b %wcache < 60%
vmstat -p fpi、fpo		 100パーセントが理想です。メモリ不足によるキャッシュのヒット率低下は性能低下の大きな要因です。出来るだけ大きな物理メモリを実装して下さい。ディスクバッファサイズは大きく見積もると全ファイル合計サイズの2%、小さく見積もると全ファイル合計サイズの1%です。ただし、この計算にraw(生)モードのファイルは含みません。 直接のチューニングパラメタはありません。
メモリ 1 sar -r freemem < minfree
sar -w swpin/s != 0
sar -w swpot/s != 0
sar -g pgscan >= 200
pmap -xの出力リストから計算		 メモリ量を再計算します。場合によって物理メモリを増加する必要があります。ユーザ数やデータ量の増加によってメモリが圧迫されてきたとすると、ある時点で物理メモリを増加させる必要があります。適切なメモリ量を見積もります。この判断のためには、現在のシステムに必要なサイズを明確にしておく必要があります。妥当なメモリ使用かそうでないかを確認して下さい。また成長要因を明確にして将来の予測を立てることが重要です。なお、スワップアウトやスワップインが頻繁に発生しているようなシステムではレスポンスを期待することは出来ません。 直接のチューニングパラメタはありません。
2 sar -r freemem < lotsfree
sar -g ppgin/s、ppgout/s
スワップデバイスのsar -d %busy、avwait
iostat -x srv_tが高い値		 スワップデバイスの位置を変更します。ページアウト、ページインが頻繁で主にスワップデバイスに入出力が集中している場合は他のディスクに付加スワップ領域を割り当てます。 swap -s、-l、-aコマンド
mkfileコマンド
3 sar -r freemem <= lotsfree
sar -g pgscan >= 200
基本はphysmem < 計算値です。
データ(ヒープ)量が明確な場合は(freeswap+physmem) < 計算値。
pmap -xリスト。		 メモリページングパラメタの値を変更することがあります。ページング処理の開始タイミングを早くすることで性能向上の可能性があります。この場合、minfree < desfree < lotsfreeの関係を守る必要があります。値の決定条件としてlotsfreeはメモリの30%を超えないようにします。ただし、このチューニングは緊急避難であるため、明確なメモリ使用量が判明しメモリが不足していると判断された場合は物理メモリを増加させます。 /etc/systemファイル
set autoup=n
set tune_fs_flushr=nn
set lotsfree=nnnn(メモリの30%以下。cashfreeも同じ値にすべきです)
set desfree=nnnn(メモリの15%以下)
set minfree=nnnn(メモリの7.5%以下)
4 pmap -xリスト。およびその集計リストで共用ライブラリとテキストサイズを確認します。単純比率では判断が難しいことがあります。
trussログで共用ライブラリのパスを確認する必要もあります。		 静的(スタティック)ライブラリの共用ライブラリ化。スタティックライブラリを多用しているシステムはライブラリ部分が重複するためメモリページを余分に消費してしまいます。これらを共用ライブラリ化することでメモリを節約することが出来ます。実行プログラムは同じ名前で同じディレクトリ下のものであれば共用されますが、同じ名前でも別ディレクトリ下のものは別テキストとなり共用化されません。
同一名プログラムは一箇所に配置します。また、同一のソースコードから定数や文字列などをわずかに変更して別名のプログラムを作成すると無駄にテキスト領域を消費しますので、出来るだけパラメタや実行時環境変数等でプログラムに外部から値を渡すようにするとメモリの節約になります。		 直接のチューニングパラメタはありません。
ネットワーク 1 netstat -an
TIME_WAITコネクション数		 タイムウェイト時間を240秒から15秒(より小さい秒数でも可)に変更する。RFC1122のコメントによりネットワークコネクションの切断後浮遊パケットを保障するため2MSLの時間そのコネクションの接続テーブルを保持することになっています。これは接続テーブルを再利用する場合に有効です。しかしながら240秒(4分)の間接続テーブルを保持した場合、大きなネットワークシステムの場合、大量のTIME_WAITコネクションが保持される結果%sysを高くすることが計測されています。これを少なくすることで負荷を軽減することが出来ます。 tcp_time_wait_interval
をnddコマンドでセットします。
2 netstat -s
ｔｃｐListenDrop数		 コネクション要求を同時に受け付ける最大数を大きくします。クライアントからの接続要求がラッシュした場合にサーバ側のListenがエラーになることがあります。これを緩和するため、同時接続要求を変更します。 tcp_conn_req_max_q
tcp_conn_req_max_q0
をnddコマンドでセットします。
3 netstat -sまたは、
nddコマンドでtcp_conn_hash_sizeを表示します。		 ハッシュエントリバイト数を増加させます。TCPの制御テーブルをポイント(位置付け)するハッシュエントリは512バイトです。もし接続数が大量になるとハッシュエントリの入れ替えが頻繁になり、sar -uの%sysが高くなることがあります。これを緩和します。値は常時接続数×8(バイト)×安全率の計算結果を2のべき乗で設定します。 /etc/systemファイル
set tcp:tcp_conn_hash_size=n
4 netstat -I、netstat -s
転送データブロックは大きいはずがパケットあたりのデータ量が予想より小さい場合。		 送受信データのハイウォータ値を上げます。データ転送において上位プロトコルは大きなブロックで転送しているのにもかかわらずTCP層で分断されている傾向の時、ハイウォータ値を上げることでブロックあたりの転送バイト数が大きくなることがあります。 nddコマンドでセット
tcp_recv_hiwat
tcp_xmit_hiwat


Copyright (C) 2004 by The Art of Computer Technologies, Corp.  All rights reserved.