性能上の問題点を見つけたり,どの分野で性能が低下しているかを把握するには,性能について広範囲の情報を収集しなければなりません。
症状が明白な場合や,性能上の問題点が明示的に通知される場合もあります。 たとえば,アプリケーションが完了するまでの時間が長かったり,システムのリソース不足を示すメッセージがコンソールに表示される場合があります。 このような場合以外は,問題点や性能不足は明白ではなく,システム性能をモニタリングして初めて検出できます。
システム性能情報を取得するために使用できる各種のコマンドとユーティリティがあります。 統計情報はさまざまな条件のもとで取得することが重要です。 データのセットを比較することが,性能問題の診断に役に立ちます。
たとえば,アプリケーションがシステム性能にどのように影響を与えているのか調べるには,アプリケーションを実行していない状態で性能の統計情報を取得し,その後,アプリケーションを実行してから,同じ統計情報を取得します。 異なるデータのセットを比較すれば,アプリケーションのメモリ,CPU,またはディスク入出力の消費量がわかります。
さらに,正確な性能情報を得るには,アプリケーション処理の複数の段階で情報を収集しなければなりません。 たとえば,ある段階では入出力を多用し,別の段階では CPU を多用するアプリケーションが考えられます。
この章では,以下の内容について説明します。
性能問題の解決のための方法論的アプローチ (2.1 節)
システム・イベント情報の取得 (2.2 節)
情報収集用の基本的なツールの使用 (2.3 節)
情報収集用の補助的なツールの使用 (2.4 節)
継続的な性能モニタリング (2.5 節)
性能上の問題点を見つけたり,どの分野で性能が低下しているかを把握したら,適切な解決方法を見つけることができます。
システム性能の改善のために,アプリケーション別にチューニングを行う方法は,Part 2を参照してください。
構成要素別にチューニングを行う方法は,Part 3を参照してください。
2.1 性能問題の解決のための方法論的アプローチ
性能問題を診断するための推奨手順は 5 つあります。 最初に,性能と可用性に関する用語と概念を,十分に理解しておく必要があります。 詳細は,第 1 章 を参照してください。
また,アプリケーションがシステム・リソースをどのように使用しているかについても,理解している必要があります。 すべての構成とチューニングのガイドラインが,すべてのタイプの作業負荷に適するわけではないからです。 たとえば,アプリケーションはメモリ多用型なのか,CPU 多用型なのかを調べる必要があります。 あるいは,ディスク操作が多いのか,ネットワーク操作が多いのかを調べる必要があります。 構成に適したリソース・モデルについて詳細は,1.8 節を参照してください。
性能問題を診断するには,以下の手順を実行します。
最初に,システムのハードウェア構成を理解する必要があります。
ハードウェア構成要素を調べて,管理するには,hwmgr
ユーティリティを使用します。
詳細は,1.1 節または2.3.1 項を参照してください。
システム性能のチューニングに使用するオペレーティング・システムのパラメータとカーネル属性を分析してから,sys_check
ユーティリティを実行します。
このツールは性能問題を診断するために使用できます。
詳細は,2.3.3 項を参照してください。
ソフトウェアの構成エラーを確認し,認識しておきます。
sys_check
を使用して,性能問題を診断することもできます。
システム・イベントの情報の取得方法は,2.2 節を参照してください。
どのようなタイプのアプリケーションを使用しているか確認し,アプリケーションを,Oracle,ネットワーク・ファイル・システム,またはインターネット・サーバに分類します。 システムをアプリケーション別にチューニングする場合は,以下の章を参照してください。
ボトルネック,つまり性能低下の原因となっているシステム・リソースを調べます。 以下の情報をプロットして,性能問題を判断します。
CPU -- アイドル・システム時間とユーザ時間
メモリ -- プロセス,UBC および固定メモリによって使用されているアクティブ・ページと非アクティブ・ページの合計。
ディスク入出力 -- 秒当たりのトランザクション数と秒当たりのブロック数
collect
コマンドを使用して,システムに負荷がかかっている時間,または性能問題が現れている時間の性能データを取得します。
性能情報を取得した後,collgui
グラフィカル・インタフェースを使用して,データをプロットします。
collgui
の使用方法は,2.3.2.2 項を参照してください。
作業負荷に適したリソース・モデルについては,1.8 節を参照してください。
システム・イベントを継続的にモニタリングし,重大な問題が発生した場合に警告を発するルーチンを設定してください。 定期的にイベントやログ・ファイルを調べると,性能や可用性に影響が現われる前に問題点を修正できます。 また,性能上の問題の診断が容易になります。
システム・イベントのログは,システム・イベント・ロギング機能と,バイナリ・イベント・ロギング機能によって取得されます。
システム・イベント・ロギング機能では,syslog
関数を使用して,ASCII 形式でイベントのログを取得します。
syslogd
デーモンは,各種のカーネル,コマンド,ユーティリティ,アプリケーション・プログラムで取得されたログ・メッセージを収集します。
そしてこのデーモンは,/etc/syslog.conf
イベント・ロギング構成ファイルで指定されているとおりに,メッセージをローカル・ファイルに書き込むか,メッセージをリモート・システムに転送します。
これらの ASCII ログ・ファイルを定期的にモニタリングして,性能情報を入手してください。
バイナリ・イベント・ロギング機能では,カーネル内のハードウェア・イベントとソフトウェア・イベントを検出し,詳細情報のログをバイナリ形式のレコードで記録します。
バイナリ・イベント・ロギング機能では,binlogd
デーモンを使用して,各種のイベント・ログ・レコードを収集します。
そしてこのデーモンは,省略時の構成ファイル
/etc/binlog.conf
で指定されているとおりに,レコードをローカル・ファイルに書き込むか,リモート・システムに転送します。
バイナリ・イベント・ログ・ファイルは,次の方法で調査できます。
イベント・マネージャ (EVM) は,バイナリ・ログ・ファイルを使用して,イベント通知を必要とする関係者へイベント情報を通知し,すぐにまたは後でアクションをとれるようにします。 EVM についての詳細は,2.2.1 項を参照してください。
DECevent ユーティリティは,規則に基づいて変換と通知を行うユーティリティであり,バイナリ・エラー・ログ・イベントのイベント変換を行います。
EVM は DECevent の変換機能
dia
を使用して,バイナリ・エラー・ログ・イベントを,人が読める形式に変換します。
Compaq Analyze は,EV6 シリーズのいくつかのプロセッサで,同じような役割を果たします。
DECevent についての詳細は,2.2.2 項
または
dia
(8)
Compaq Analyze についての詳細は,2.2.3 項
または
ca
(8)
また,クラッシュ・ダンプ・サポートをシステムに構成してください。 性能上の重大な問題によってシステム・クラッシュが引き起こされることがあります。 クラッシュ・ダンプ分析ツールを使用すると,性能上の問題点を診断するのに役立ちます。
イベント・ログとクラッシュ・ダンプについての詳細は,『システム管理ガイド』を参照してください。
2.2.1 イベント・マネージャの使用
イベント・マネージャ (EVM) を使用すると,イベント情報を取得して,この情報を必要とする関係者へ通知し,すぐにまたは後でアクションをとることができます。 イベント・マネージャには,次の機能があります。
カーネル・レベルおよびユーザ・レベルのプロセスおよび構成要素がイベントを通知できるようにする。
プログラムやユーザなどのイベントの受信者が,選択したイベントの発生時に通知を受け取れるようにする。
バイナリ・ロガー・デーモンなどの,既存のイベント・チャネルをサポートする。
ユーザがイベントを参照できるように,グラフィカル・ユーザ・インタフェース (GUI) を提供する。
イベントを通知したり受け取ったりするルーチンをプログラマが作成できるように,アプリケーション・プログラミング・インタフェース (API) ライブラリを提供する。
EVM 環境を構成し管理するためのコマンド行ユーティリティ (管理者用) と,イベントの通知や取り出しを行うためのコマンド行ユーティリティ (ユーザ用) をサポートする。
EVM についての詳細は,『システム管理ガイド』を参照してください。
2.2.2 DECevent の使用
DECevent ユーティリティは,バイナリ・イベント・ロギング機能を使用して継続的にシステム・イベントをモニタリングし,イベントをデコードして,システム装置が取得したイベントの数と重大度を追跡します。 DECevent はシステム・イベントを分析し,障害が発生した装置を切り分け,発生する可能性のある問題についての警告を行う通知メカニズム (メールなど) を提供します。
DECevent の分析および通知機能を使用するには,ライセンスを登録しなければなりません。 または,これらの機能がサービス契約に含まれている場合もあります。 DECevent を使って,バイナリ・ログ・ファイルを ASCII 形式へ変換するだけなら,ライセンスは不要です。
詳細は,『DECevent Translation and Reporting Utility』を参照してください。
2.2.3 Compaq Analyze の使用
Compaq Analyze は,単一のエラー/障害イベントの分析,多重イベントの分析および複合分析を行う障害分析ユーティリティです。 Compaq Analyze は,従来のバイナリ・エラー・ログの他に,他のエラー/障害データ・ソースを使用してシステム分析を行います。
Compaq Analyze は,アクティブなエラー・ログをモニタリングし,発生したイベントをリアルタイムに処理することにより,自動分析をバックグラウンドで行います。 エラー・ログ・ファイルのイベントは,分析規則と照らし合わせてチェックされます。 エラー・ログ・ファイルに規則に指定された条件を満たすイベントが 1 つ以上あると,分析エンジンがエラー・データを収集して,問題の説明や必要な修正作業などを記載した問題レポートを作成します。 問題レポートは,いったん作成されると,通知の設定に従って配信されます。
最新の Alpha EV6 プロセッサでは,Compaq Analyze のみがサポートされ,DECevent はサポートされていないので注意してください。
Compaq Analyzeとその他の WEBES (Web Based Enterprise Service Suite) ツール,およびドキュメントの最新バージョンは,次の場所からダウンロードできます。
http://www.compaq.com/support/svctools/webes
Web サイトからキットをダウンロードして,/var/tmp/webes
に保存します。
キットは,次のようなコマンドを用いて展開します。
#
tar -xvf <tar file name>
次のコマンドを使用して,Compaq Web Based Enterprise Service Suite をインストールします。
#
setld -l /var/temp/webes/kit
インストレーションの際には,省略時のオプションを選択して構いません。
ただし,オプションの WEBES ツールをすべてインストールする必要はありません。
EVM が使用するのは Compaq Analyze のみです。
詳細は,別冊の Compaq Analyze
のマニュアルと,
ca
(8)2.2.4 システム課金とディスク・クォータの使用
各ユーザが消費しているリソースの情報を取得できるように,システム課金を設定してください。 課金によって,CPU の使用量および接続時間,生成したプロセス数,メモリおよびディスクの使用量,入出力動作の回数,印刷動作の回数を追跡できます。
ディスク使用量を追跡して制御するには,AdvFS (Advanced File System) および UNIX ファイル・システム (UFS) のディスク・クォータを構成しなければなりません。 ディスク・クォータを使用すると,ユーザが利用できるディスク・スペースを制限でき,ディスク・スペースの使用量を監視できます。
システム課金と UFS ディスクのクォータについては,『システム管理ガイド』を参照してください。
AdvFS クォータについては,『AdvFS 管理ガイド』 を参照してください。
2.3 情報収集用の基本的なツール
以下のユーティリティが,情報収集用の基本的なツールです。
2.3.1 hwmgr ユーティリティを使用したハードウェア情報の収集
ハードウェア管理に使用する基本的なツールは,hwmgr
コマンド行インタフェース (CLI) です。
SysMan タスクのようなその他のインタフェースでは,hwmgr
の機能の一部しか使用できません。
hwmgr
コマンドを使用すると,不慣れなシステムに接続して,構成要素の階層に関する情報が取得できます。
そして特定の構成要素に対する属性を設定できます。
view
コマンドを使用して,システム内のハードウェアの階層を表示します。
このコマンドを使用すると,デバイスを制御しているアダプタと,アダプタがインストールされているバス上の位置を検出できます。
以下の例は,クラスタを構成していない小規模システムのハードウェア構成要素階層を示しています。
#
hwmgr view hierarchy
HWID: Hardware component hierarchy ---------------------------------------------- 1: platform AlphaServer 800 5/500 2: cpu CPU0 4: bus pci0 5: scsi_adapter isp0 6: scsi_bus scsi0 18: disk bus-0-targ-0-lun-0 dsk0 19: disk bus-0-targ-4-lun-0 cdrom0 20: graphics_controller trio0 8: bus eisa0 9: serial_port tty00 10: serial_port tty01 11: parallel_port lp0 12: keyboard PCXAL 13: pointer PCXAS 14: fdi_controller fdi0 15: disk fdi0-unit-0 floppy0 16: network tu0 17: network tu1 output truncated
階層上で複数のエントリとして表示される構成要素もあります。 たとえば,ディスクが 2 つのアダプタで共用される SCSI バス上にある場合,階層上には同一デバイスに対して 2 つのエントリが表示されます。 同様のハードウェア構成要素の階層は,SysMan Station GUI を使用しても表示できます。 SysMan Menu を実行するための方法は,『システム管理ガイド』を参照してください。 13.2.2.6 項 には,グラフィカル・インタフェースの使用方法を示しています。 有効なデータ・エントリについての詳細は,オンライン・ヘルプを参照してください。
階層内の特定の構成要素を参照するには,grep
コマンドを使用します。
次の例は,CPU のハードウェア構成要素についての出力を示しています。
#
hwmgr view hierarchy | grep "cpu"
2: cpu qbb-0 CPU0 3: cpu qbb-0 CPU1 4: cpu qbb-0 CPU2 5: cpu qbb-0 CPU3 7: cpu qbb-1 CPU5 8: cpu qbb-1 CPU6 9: cpu qbb-1 CPU7 10: cpu qbb-2 CPU8 11: cpu qbb-2 CPU9 12: cpu qbb-2 CPU10 13: cpu qbb-2 CPU11
階層表示
コマンドは,システム階層に入っている現在登録済みのハードウェア構成要素を表示します。
フラグ・ステータスを持った構成要素は,コマンド出力の中の以下のコードで区別できます。
(!
) 警告
(X
) クリティカル
(-
) 非アクティブ
これらのコードについての説明は,
hwmgr
(8)
システムに接続されているすべての SCSI デバイス (ディスクとテープ) を参照するには,次のコマンドを実行します。
#
hwmgr show scsi
ホストから認識できる RAID アレイ・コントローラを参照するには,次のコマンドを実行します。
#
hwmgr show scsi | grep scp
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ------------------------------------------------------------------------- 266: 30 wf99 disk none 0 20 scp0 [2/0/7] 274: 38 wf99 disk none 0 20 scp1 [2/1/7] 282: 46 wf99 disk none 0 20 scp2 [2/2/7] 290: 54 wf99 disk none 0 20 scp3 [2/3/7] 298: 62 wf99 disk none 0 20 scp4 [2/4/7] 306: 70 wf99 disk none 0 20 scp5 [2/5/7] 314: 78 wf99 disk none 0 20 scp6 [2/6/7] 322: 86 wf99 disk none 0 20 scp7 [2/7/7] 330: 94 wf99 disk none 0 20 scp8 [2/8/7] 338: 102 wf99 disk none 0 20 scp9 [2/9/7] 346: 110 wf99 disk none 0 20 scp10 [2/10/7] 354: 118 wf99 disk none 0 20 scp11 [2/11/7]
この例で
scp
は,サービス制御ポートを表わし,RAID アレイ (HSG) が管理と診断のために提供するアドレスを示します。
hwmgr
コマンドの詳細は,『ハードウェア管理ガイド』または
hwmgr
(8)2.3.2 collect ユーティリティを使用したシステム情報の収集
collect
ユーティリティは,特定のオペレーティング・システムのデータを記録または表示する,システム・モニタリング・ツールです。
これは,ファイル・システム,メモリ,ディスク,プロセス・データ,CPU,ネットワーク,メッセージ・キュー,LSM,その他の重要なシステム性能情報も収集します。
collect
ユーティリティのオーバヘッドはわずかで,高い信頼性があります。
データ収集とプレイバックを柔軟に切り替える機能もあります。
収集したデータは,ターミナルに表示するか,または圧縮または非圧縮のいずれかのデータ・ファイルとして保存します。
そのデータ・ファイルは,コマンド行からの読み取りと操作が可能です。
collect
ユーティリティは,信頼できる統計情報を提供するために,ページ・ロック関数の
plock()
を使用してメモリにロックし,省略時の設定では,システムによってスワップ・アウトされることはありません。
また,優先度関数
nice()
を使用して,優先度も上げています。
それでも,通常の負荷のもとではシステムに影響を与えることはありません。
極端に負荷が高い場合でも,システムには最小限の影響しか与えません。
collect
ユーティリティは,collgui
グラフィカル・ユーザ・インタフェース,またはコマンド行から起動します。
グラフィカル・ユーザ・インタフェースを使用している場合には,コマンド行から
cfilt
を実行し,collgui
とユーザ・スクリプトで使用される
collect
のデータをフィルタ処理してください。
詳細は,
collect
(8)
次の例は,標準的な 10 秒間隔で完全なデータ収集を実行し,出力をターミナルに表示する方法を示しています。
#
/usr/sbin/collect
このコマンドは,
vmstat
(1)iostat
(1)netstat
(1)volstat
(8)
サブシステムをデータ収集の対象に含めるには,-s オプションを使用します。 サブシステムをデータ収集の対象から外すには,-e (除外) オプションを使用します。
以下の出力では,ファイル・システム・サブシステムのデータ収集だけを指定しています。
#
/usr/sbin/collect -sf
# FileSystem Statistics # FS Filesystem Capacity Free 0 root_domain#root 128 30 1 usr_domain#usr 700 147 3 usr_domain#var 700 147
オプション文字は,以下のサブシステムを表わしています。
p -- プロセス・データを指定
m -- メモリ・データを指定
d -- ディスク・データを指定
l -- LSM ボリューム・データを指定
n -- ネットワーク・データを指定
c -- CPU データを指定
f -- ファイル・システム・データを指定
tyy -- ターミナル・データを指定
プロセス・データを収集する場合は,-S (ソート) オプションと -n X (数) オプションを使用して,CPU 使用率でデータをソートし,X 個のプロセスだけを保存します。 Plist オプションを使用すると,特定のプロセス群を対象にできます。 ただし,list は,コンマで区切られた プロセス ID のリストです。
モニタリング対象のシステムに接続されているディスクが多い場合 (100 以上) は,-D オプションを使用して,ディスクの特定のサブセットをモニタリングするようにします。
collect
ユーティリティに
-p
オプションを指定すると,複数のバイナリ・データ・ファイルを読み込み,サンプル番号を単調に増加させるような形で,1 つのストリームとして出力します。
複数のバイナリ入力ファイルを,1 つのバイナリ・データ・ファイルに結合することもできます。
その場合,-p
オプションに入力ファイルを指定し,-f
オプションに出力ファイルを指定します。
collect
ユーティリティは入力ファイルを,コマンド行で指定する任意の順序で結合します。
そのため,結合された出力ファイルを将来処理したいのであれば,入力ファイルは完全に時間軸に対応させる必要があります。
異なるシステムの,異なる時刻に作成された,異なるサブシステムのサブセットのデータを収集した,複数のバイナリ入力ファイルを結合することもできます。
このユーティリティでは,-e,-s,-P,および
-D
のようなフィルタ処理用オプションを使用できます。
詳細は,
collect
(8)2.3.2.1 collect をシステム・リブート時に自動的に起動するための構成
collect
を構成して,システム・リブート時に自動的に起動するようにできます。
こうすると,サブシステムやプロセスの継続的モニタリングを行う場合に,特に役に立ちます。
これは障害と性能問題の診断に有効です。
各システムで
rcmgr
コマンドに
set
操作を指定して使用し,次のように,/etc/rc.config*
ファイル内に以下の値を構成します。
%
rcmgr set COLLECT_AUTORUN 1
1 の値を使用すると,collect
はシステム・リブート時に自動的に起動されます。
0 の値 (省略時の値) を使用すると,collect
はリブート時には起動されません。
%
rcmgr set COLLECT_ARGS " -ol -i 10:60 \ -f /var/adm/collect.dated/collect -H d0:5,1w "
ヌル値を指定すると,collect
は以下に示す省略時の値で起動されます。
-i60, 120 -f /var/adm/collect.dated -W 1h -M 10, 15
collect
の直接出力は,NFS にマウントされているファイル・システムではなく,ローカル・ファイル・システムに書き出す必要があります。
これはシステムやネットワークの問題の発生時に重要な診断データを失うことを防止するためです。
また,ファイル・システムが応答しないことで
collect
の出力がブロックされて,その結果システム問題が発生することを防ぐためです。
詳細は,
rcmgr
(8)2.3.2.2 collect データ・ファイルのプロット
collect
コマンドの
collgui
グラフィカル・インタフェース,または
collect
コマンドの
cflit
フィルタのいずれかを使用して,collect
データ・ファイルを Excel にエクスポートします。
注意
collgui
を実行するには,Perl と Perl/TK が必要です。 これは次の URL でcollect
の FTP サイトから,無償でダウンロードできます。 ftp://ftp.digital.com/pub/DEC/collect
collgui
グラフィカル・インタフェースを使用して,情報をプロットするには,以下の手順を実行します。
collgui
をデバッグ・モードで実行します。
>> collgui -d "collect datafile"
サブシステムを選択し,[Display] をクリックします。
collgui
を起動したシェルに戻ります。
collgui
によって,/var/tmp
ディレクトリが作成されたことがわかります。
ファイル名は,collgui.xxxx
です。
ここで,xxxx
は整数です。
データ・ファイル (collgui.xxxx
) は,Excel にエクスポートすることができます。
これを Windows システムへコピーします。
Windows システムで Excel を起動し,collgui.xxxx
を開きます。
「ファイルの種類」フィールドでは,「すべてのファイル (*.*)」を選択する必要があります。
Excel 2000 で,「テキストファイルウィザード」が開きます。
Excel 2000 で,「データのファイル形式」で [コンマやタブなどの区切り文字によってフィールドごとに区切られたデータ] を選択し,[次へ] を選択します。
Excel 2000 で,「区切り文字」として [タブ] と [スペース] を選択します。 そして,[次へ] を選択します。
「データのプレビュー」ペインで,シフト・キーを使用してインポートする列を選択し,[完了] を選択します。
ワークシートに列が表示されます。
cflit
collect フィルタを使用して情報をプロットするには,以下の手順を実行します。
cfilt
を使用して,データ・ファイルを作成します。
たとえば,データの処理に使用されている
system time
,physical memory
,そして「Single CPU」フィールドに待ち時間,user+system time
を表示するように選択するには,次のコマンドを実行します。
cfilt -f "collect datafile" 'sin:WAIT:USER+SYS' 'pro:Systim#:RSS#' > /var/tmp/collgui.xxxx
collgui
データ・ファイルを Windows システムにコピーします。
上述の
collgui
での手順中,手順 4〜9 を実行します。
詳細は,次の Web アドレスを参照してください。
http://www.tru64unix.compaq.com/collect/collect_faq.html
2.3.3 sys_check ユーティリティを使用した構成のチェック
sys_check
ユーティリティは,システム性能のチューニングに使用する,オペレーティング・システムのパラメータとカーネル属性の分析を実行します。
このユーティリティは,メモリ・リソースと CPU リソースをチェックし,SMP システムとカーネル・プロファイルの性能データとロック統計情報を作成し,警告とチューニングのガイドラインを出力します。
sys_check
ユーティリティは,システム構成を説明する HTML ファイルを作成するので,問題を診断するために使用することができます。
sys_check
で作成されるレポートには,現在の設定で問題があれば,警告が表示されます。
システム状態を完全に概観し,制御するには,sys_check
ユーティリティは,イベント管理およびシステム・モニタリング・ツールとともに使用する必要があります。
高度なチューニング・ガイドラインを適用する前に,sys_check
ユーティリティが出力した構成およびチューニングのガイドラインを適用することを検討してください。
注意
sys_check
ユーティリティの動作中は,システムの性能が低下することがあります。 性能への影響を最小限に抑えるには,負荷が少ない時間帯にこのユーティリティを実行してください。
sys_check
ユーティリティは,SysMan のグラフィカル・ユーザ・インタフェースとコマンド行のどちらでも起動できます。
sys_check
にコマンド行オプションを指定しなかった場合は,基本的なシステム分析が行われ,構成およびチューニングのガイドラインを示す HTML ファイルが作成されます。
コマンド行で指定できるオプションを,次に示します。
-all
オプションでは,セキュリティ情報および
setld
インベントリ確認を含む,すべてのサブシステム情報が出力されます。
-perf
オプションでは,性能データだけが出力され,構成データは出力されません。
完了するまでに,5〜10 分の時間がかかります。
-escalate
オプションでは,障害を報告する場合に必要となるエスカレーション・ファイルが作成されます。
詳細は,
sys_check
(8)2.4 情報収集用の補助的なツール
以下に示すユーティリティが,性能情報収集用の補助的なツールです。
システム情報の収集
ネットワーク情報の収集
nfsstat
ユーティリティ (2.4.3 項)
tcpdump
ユーティリティ (2.4.4 項)
netstat
コマンド (2.4.5 項)
ps axlmp
コマンド (2.4.6 項)
nfsiod
デーモン (2.4.7 項)
nfswatch
コマンド (2.4.8 項)
2.4.1 lockinfo ユーティリティを使用したロック統計情報の収集
lockinfo
ユーティリティを使用すると,カーネル SMP ロックのロック統計情報の収集と表示が行われます。
このユーティリティはデータを収集するために,/dev/lockdev
擬似ドライバを使用します。
ロック統計情報は,generic
サブシステムの
lockmode
属性が,2 (省略時の値),3,または 4 のときに収集されます。
lockinfo
で統計情報を収集するには,以下の手順を実行します。
システムに作業負荷を発生させ,それが安定状態になるまで待ちます。
sleep
コマンドを指定し,適当な秒数を
cmd_args
に指定して
lockinfo
を起動します。
これにより,lockinfo
は
sleep
コマンドを実行している間の統計情報を収集します。
最初の一連の結果に基づき,lockinfo
を再び実行します。
今度は,システムの性能問題の原因になる可能性のある (たとえばミス率の高い) 結果を表示するために,いずれかのロック・クラスの特定の情報を要求します。
次の例は,60 秒間だけ各プロセッサのロック統計情報を収集する方法を示しています。
#
lockinfo -percpu sleep 60
hostname: sysname.node.corp.com lockmode: 4 (SMP DEBUG with kernel mode preemption enabled) processors: 4 start time: Wed Jun 9 14:45:08 1999 end time: Wed Jun 9 14:46:08 1999 command: sleep 60 tries reads trmax misses percent sleeps waitmax waitsum misses seconds seconds bsBuf.bufLock (S) 0 1400786 0 45745 47030 3.4 0 0.00007 0.15526 1 1415828 0 45367 47538 3.4 0 0.00006 0.15732 2 1399462 0 33076 48507 3.5 0 0.00005 0.15907 3 1398336 0 31753 48867 3.5 0 0.00005 0.15934 ----------------------------------------------------------------------- ALL 5614412 0 45745 191942 3.4 0 0.00007 0.63099 lock.l_lock (S) 0 1360769 0 40985 18460 1.4 0 0.00005 0.04041 1 1375384 0 20720 18581 1.4 0 0.00005 0.04124 2 1375122 0 20657 18831 1.4 0 0.00009 0.04198 ----------------------------------------------------------------------- ALL 5483049 0 40985 74688 1.4 0 0.00009 0.16526 ...inifaddr_lock (C) 0 0 0 1 0 0.0 0 0.00000 0.00000 1 1 1 1 0 0.0 0 0.00000 0.00000 2 0 0 1 0 0.0 0 0.00000 0.00000 3 0 0 1 0 0.0 0 0.00000 0.00000 ----------------------------------------------------------------------- ALL 1 1 1 0 0.0 0 0.00000 0.00000 total simple_locks = 28100338 percent unknown = 0.0 total rws_locks = 1466 percent reads = 100.0 total complex_locks = 2716146 percent reads = 33.2 percent unknown = 0.0
ロック問題は,特定のリソースに対して多くの競合があることです。 入出力に関連するロックに競合が存在し,特定のアプリケーションが同一のファイルやディレクトリで競合する多くのプロセスを生成している場合,アプリケーションやデータベース・ストレージの設計を再調整することが必要です。
System V セマフォを使用しているアプリケーションは,単一のセマフォ・セットで非常に多数のセマフォを作成していると,カーネルはセマフォの各セットごとにロックを使用するので,時としてロック競合問題を起こします。 この場合,アプリケーションでは,使用するセマフォ・セットの数を増やし,各セマフォ・セットのセマフォの数を減らすようにすれば,性能が改善します。
詳細は,
lockinfo
(8)2.4.2 sched_stat ユーティリティを使用した CPU 利用率とプロセス統計情報の収集
sched_stat
ユーティリティは,システムの負荷が各 CPU に正しく分散されているか,どのジョブが各 CPU で十分な実行時間を与えられているか,またはいないか,そしてこれらのジョブに対してキャッシュが有効に使用されているか,というような項目を調べるのに役に立ちます。
sched_stat
は,SMP および NUMA プラットフォームの CPU 利用率とプロセス・スケジューリングを表示します。
sched_stat
を使用して統計情報を収集するには,以下の手順を実行します。
システムの作業負荷を発生させ,それが安定状態になるまで待ちます。
sleep
コマンドを指定し,適当な秒数を
cmd_args
に指定して
sched_stat
を起動します。
これにより,sched_stat
は
sleep
コマンドを実行したときの統計情報を収集します。
たとえば,次のコマンドを実行すると,sched_stat
は 60 秒間の統計情報を収集し,レポートをプリントします。
#
/usr/sbin/sched_stat sleep 60
コマンド行にオプションを指定すると,指定したオプションの統計情報だけがレポートされます。
コマンド行にオプションを指定しないと,-R
を除くすべてのオプションを指定したものとして扱われます。
詳細は,
sched_stat
(8)2.4.3 nfsstat ユーティリティを使用したネットワークと NFS 統計情報の収集
クライアントおよびサーバについて NFS およびリモート・プロシージャ・コール (RPC) の統計情報を表示 (または初期化) するには,次のように入力します。
統計情報には,再送を必要としたパケット数 (retrans
),応答のトランザクション ID が要求のトランザクション ID と一致しなかった回数 (badxid
) などがあります。
#
/usr/ucb/nfsstat
以下のような情報が表示されます。
Server rpc: calls badcalls nullrecv badlen xdrcall 38903 0 0 0 0 Server nfs: calls badcalls 38903 0 Server nfs V2: null getattr setattr root lookup readlink read 5 0% 3345 8% 61 0% 0 0% 5902 15% 250 0% 1497 3% wrcache write create remove rename link symlink 0 0% 1400 3% 549 1% 1049 2% 352 0% 250 0% 250 0% mkdir rmdir readdir statfs 171 0% 172 0% 689 1% 1751 4% Server nfs V3: null getattr setattr lookup access readlink read 0 0% 1333 3% 1019 2% 5196 13% 238 0% 400 1% 2816 7% write create mkdir symlink mknod remove rmdir 2560 6% 752 1% 140 0% 400 1% 0 0% 1352 3% 140 0% rename link readdir readdir+ fsstat fsinfo pathconf 200 0% 200 0% 936 2% 0 0% 3504 9% 3 0% 0 0% commit 21 0% Client rpc: calls badcalls retrans badxid timeout wait newcred 27989 1 0 0 1 0 0 badverfs timers 0 4 Client nfs: calls badcalls nclget nclsleep 27988 0 27988 0 Client nfs V2: null getattr setattr root lookup readlink read 0 0% 3414 12% 61 0% 0 0% 5973 21% 257 0% 1503 5% wrcache write create remove rename link symlink 0 0% 1400 5% 549 1% 1049 3% 352 1% 250 0% 250 0% mkdir rmdir readdir statfs 171 0% 171 0% 713 2% 1756 6% Client nfs V3: null getattr setattr lookup access readlink read 0 0% 666 2% 9 0% 2598 9% 137 0% 200 0% 1408 5% write create mkdir symlink mknod remove rmdir 1280 4% 376 1% 70 0% 200 0% 0 0% 676 2% 70 0% rename link readdir readdir+ fsstat fsinfo pathconf 100 0% 100 0% 468 1% 0 0% 1750 6% 1 0% 0 0% commit 10 0%
呼び出しのタイムアウト率 (1 パーセントを超えないようにしてください) は,NFS の統計情報を見る上で最も重要な事項です。 呼び出しのタイムアウト率が 1 パーセントを超えると,性能にかなりの悪影響があります。 タイムアウトを避けるようにシステムをチューニングする方法は,第 10 章を参照してください。
NFS および RPC の情報を一定間隔 (秒) で表示するには,次のように入力します。
#
/usr/ucb/
nfsstat -s -i number
次の例は,10 秒間隔で NFS および RPC 情報を表示します。
#
/usr/ucb/
nfsstat -s -i 10
nfsstat
で試験的にモニタリングする場合は,試験を開始する前に NFS カウンタを 0 にリセットしてください。
NFS カウンタをリセットして 0 にするには,次のように入力します。
#
/usr/ucb/
nfsstat -z
コマンドのオプションと出力についての詳細は,
nfsstat
(8)2.4.4 tcpdump ユーティリティを使用した情報の収集
tcpdump
ユーティリティは,ネットワーク・インタフェース上のパケット・ヘッダをモニタリングし,表示します。
リッスンしているインタフェース,パケット転送の方向,あるいはプロトコル・トラフィックのタイプを表示対象として指定できます。
tcpdump
を使用すると,特定のネットワーク・サービスに関連するネットワーク・トラフィックをモニタリングでき,パケットの送信元を調べることができます。
これにより,要求が受信されたか,または受信に対し肯定応答があったかを調べることができます。
また,ネットワーク性能が低い場合には,ネットワーク要求の送信元を調べることができます。
このコマンドを使用するには,次の例のように,カーネルに
packetfilter
オプションが構成されている必要があります。
#
pfconfig +p +c tu0
netstat -ni
コマンドを使用すると,次のように,構成されているネットワーク・インタフェースが表示されます。
#
netstat -ni
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll tu0 1500 <Link> 00:00f8:22:f8:05 486404139 010939748 632583736 tu0 1500 16.140.48/24 16.140.48.156 486404139 010939748 632583736 tu0 1500 DLI none 486404139 010939748 632583736 sl0* 296 <Link> 0 0 0 0 0 lo0 4096 <Link> 1001631086 0 1001631086 0 0 lo0 4096 127/8 127.0.0.1 1001631086 0 1001631086 0 0
netstat
コマンドの出力を使用して,tcpdump
で指定するインタフェースを決定します。
たとえば,次のとおりです。
#
tcpdump -mvi tu0 -Nts1500
tcpdump: listening on tu0 Using kernel BPF filter k-1.fc77a110 > foo.pmap-v2: 56 call getport prog "nfs" V3 prot UDP port 0 \ (ttl 30, id 20054) foo.fc77a110 > k-1.pmap-v2: 28 reply getport 2049 (ttl 30, id 36169) k-1.fd77a110 > foo.pmap-v2: 56 call getport prog "mount" V3 prot UDP port 0 \ (ttl 30, id 20057) foo.fd77a110 > k-1.pmap-v2: 28 reply getport 1030 (ttl 30, id 36170) k-1.fe77a110 > foo.mount-v3: 112 call mount "/pns2" (ttl 30, id 20062) foo.fe77a110 > k-1.mount-v3: 68 reply mount OSF/1 fh 19,17/1.4154.1027680688/4154.\ 1027680688 (DF) (ttl 30, id 36171) k-1.b81097eb > fubar.nfs-v3: 136 call fsinfo OSF/1 fh 19,17/1.4154.1027680688/4154.\ 1027680688 (ttl 30, id 20067)
-s snaplen オプションを指定すると,省略時の値の 68 バイトではなく,各パケットのデータの snaplen バイト分が表示されます。 省略時の値は,IP,ICP,TCP,および UDP に対しては十分ですが,NFS および RPC で十分な結果を必要とする場合には,500〜1500 バイトをお勧めします。
詳細は,
tcpdump
(8)packetfilter
(7)2.4.5 netstat コマンドを使用したネットワーク統計情報のモニタリング
ネットワークの統計情報を調べるには,netstat
コマンドを使用します。
検出する問題には,次のようなものがあります。
netstat -i
command コマンドで,入力エラー (Ierrs
),出力エラー (Oerrs
),または衝突 (Coll
) が大量に表示される場合は,ネットワークに問題があることを示しています。
たとえば,ケーブルが正しく接続されていないか,またはイーサネットが飽和状態になっている場合があります (2.4.5.1 項を参照)。
netstat -is
コマンドを使用して,ネットワーク・デバイス・ドライバのエラーを調べます (2.4.5.2 項を参照)。
netstat -m
コマンドを使用して,ネットワークで使っているメモリが,システムにインストールされているメモリの総計に対して多すぎないか調べます。
netstat -m
コマンドの出力が,メモリへのいくつかの要求が待たされるか拒否されていることを示している場合は,物理メモリを一時的に使い果たしているか,またはカーネルの
malloc
空きリストが空になっています (2.4.5.3 項を参照)。
各ソケットでネットワーク接続が行われます。
システムで割り当てられているソケット数が極端に多い場合は,netstat -an
コマンドを用いてネットワーク接続の状態を調べてください (2.4.5.4 項を参照)。
インターネット・サーバの場合は,大多数の接続は
TIME_WAIT
状態になっています。
netstat -p ip
コマンドを使用して,チェックサムの間違い,長さの問題,過度のリダイレクション,リソースの問題によるパケットの紛失をチェックします (2.4.5.5 項を参照)。
netstat -p tcp
コマンドを使用して,再送,パケットの順序の乱れ,チェックサムの間違いをチェックします (2.4.5.6 項を参照)。
netstat -p udp
コマンドを使用すると,不正チェックサムとフル・パケットがチェックされます (2.4.5.6 項を参照)。
netstat -rs
コマンドを使用して,ルーティングの統計情報を取得します (2.4.5.7 項を参照)。
netstat -s
コマンドを使用して,IP,ICMP,IGMP,TCP,および UDP プロトコル層に関連する統計情報を表示できます (2.4.5.8 項を参照)。
netstat
で出力される情報のほとんどは,チューニングの可能性を調べるために使用されるのではなく,ネットワークのハードウェアまたはソフトウェアの障害を診断するために使用されます。
障害の診断方法についての詳細は,『ネットワーク管理ガイド:接続編』を参照してください。
各種のコマンド・オプションで生成される出力についての詳細は,
netstat
(1)2.4.5.1 入出力エラーと衝突
ネットワーク上の衝突は,ネットワーク上では普通に発生します。
2 つ以上のイーサネット・ステーションが,ネットワーク上で同時に送信を試みると,衝突が発生します。
ステーションが,別のステーションで既にネットワークが使われているために,ネットワークを使用できない場合には,そのステーションはネットワークに対するアクセスを少しの時間待ちます。
ステーションがネットワークにアクセスできない場合,常に衝突が発生します。
大部分のネットワーク・インタフェース・カード (NIC) は最大 15 回の再送を試み,その後出力パケットを廃棄し,excessive collisions
エラーを発行します。
netstat -i
コマンドの出力を使って,入力エラー (Ierrs
),出力エラー (Oerrs
),あるいは衝突 (Coll
) をチェックします。
これらのフィールドの値を,送信パケットの総数と比較します。
値が大きいとネットワークに問題がある可能性があります。
たとえば,ケーブルが正しく接続されていなかったり,イーサネットが飽和状態になっています。
10% 未満の衝突率では,トラフィックの多いイーサネットでは問題とは言えません。
しかし,衝突率が 20% を越えていると,問題があります。
netstat -i
コマンドの例は,次のとおりです。
#
netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll tu0 1500 Link 00:00:aa:11:0a:c1 0 0 43427 43427 0 tu0 1500 DLI none 0 0 43427 43427 0 tu1 1500 Link bb:00:03:01:6c:4d 963447 138 902543 1118 80006 tu1 1500 DLI none 963447 138 902543 1118 80006 tu1 1500 o-net plume 963447 138 902543 1118 80006 . . .
netstat -is
コマンドを使用して,次のように,ネットワーク・デバイス・ドライバのエラーをチェックします。
#
netstat -is
tu0 Ethernet counters at Tue Aug 3 13:57:35 2002 191 seconds since last zeroed 14624204 bytes received 4749029 bytes sent 34784 data blocks received 11017 data blocks sent 2197154 multicast bytes received 17086 multicast blocks received 1894 multicast bytes sent 17 multicast blocks sent 932 blocks sent, initially deferred 347 blocks sent, single collision 666 blocks sent, multiple collisions 0 send failures 0 collision detect check failure 1 receive failures, reasons include: Frame too long 0 unrecognized frame destination 0 data overruns 0 system buffer unavailable 0 user buffer unavailable
この例では,システムは 11,017 ブロックを送信したことが示されています。 これらのブロックのうち,1,013 (347 + 666) ブロックは衝突を起こし,送信したブロックのおよそ 10% が衝突したことを示しています。 10% 未満の衝突率はトラフィックの多いイーサネットでは問題とは言えません。 しかし,衝突率が 20% を越えていると,問題があります。
また,以下のフィールドは,0 もしくは 小さな 1 桁の数字である必要があります。
send failures
receive failures
data overruns
system buffer unavailable
user buffer unavailable
netstat -m
は,mbuf
クラスタで使用されるメモリを含む,ネットワーク関連のメモリ構造体の統計情報を表示します。
このコマンドを使用すると,ネットワークがシステムにインストールされているメモリの総容量に対して過度の割合でメモリを使用しているかどうかを調べることができます。
netstat -m
コマンドによって,メモリ (mbuf
) クラスタに対するいくつかの要求が,遅延されている,または拒否されていることが示されると,システムには物理メモリが一時的に不足していることがわかります。
次の例は,128 MB のメモリを備え,mbuf
クラスタの圧縮を有効にしていないファイアウォール・サーバの例です。
#
netstat -m
2521 Kbytes for small data mbufs (peak usage 9462 Kbytes) 78262 Kbytes for mbuf clusters (peak usage 97924 Kbytes) 8730 Kbytes for sockets (peak usage 14120 Kbytes) 9202 Kbytes for protocol control blocks (peak usage 14551 2 Kbytes for routing table (peak usage 2 Kbytes) 2 Kbytes for socket names (peak usage 4 Kbytes) 4 Kbytes for packet headers (peak usage 32 Kbytes) 39773 requests for mbufs denied 0 calls to protocol drain routines 98727 Kbytes allocated to network
この例では,39,773 回メモリ要求が拒否されていることが示されています。
この値は 0 である必要があるので,問題があることを示しています。
またこの例では,78 MB のメモリが
mbuf
クラスタに割り当てられており,98 MB のメモリがネットワーク・サブシステムで使用されていることが示されています。
ソケット
・サブシステムの属性
sbcompress_threshold
を 600 に増やすと,ネットワーク・サブシステムに割り当てられているメモリは即座に 18 MB に下がります。
カーネル・ソケット・バッファ・インタフェースで圧縮を行うと,メモリが効率良く使用されるようになるからです。
sbcompress_threshold
属性の詳細は,6.2.3.3 項を参照してください。
2.4.5.4 ソケット接続
ソケットごとに,ネットワーク接続が行われます。
システムが過度の数ソケットを割り当てている場合には,netstat -an
コマンドを使用して,既存のネットワーク接続の状態を調べます。
以下の例は,プロトコル制御ブロック・テーブルと各状態の TCP 接続の数を示しています。
#
netstat -an | grep tcp | awk '{print $6}' | sort | uniq -c
1 CLOSE_WAIT 58 ESTABLISHED 12 FIN_WAIT_1 8 FIN_WAIT_2 17 LISTEN 1 SYN_RCVD 15749 TIME_WAIT #
インターネット・サーバでは,通常,接続の大部分は
TIME_WAIT
状態になっています。
FIN_WAIT_1
および
FIN_WAIT_2
フィールドのエントリの数が,総接続数 (各フィールドの合計) のうちの大きな割合を示していたら,keepalive
を有効にします (6.3.2.5 項
を参照)。
SYN_RCVD
フィールド内のエントリの数が,総接続数のうちの大きな割合を示していたら,サーバが過負荷か,TCP SYN アタックを受けていることを意味します。
この例で,およそ 16,000 のソケットが使われ,16 MB のメモリが必要になっていることに注意してください。
メモリとスワップ領域の構成方法は,6.1.2 項を参照してください。
2.4.5.5 廃棄されたパケットまたは紛失したパケット
netstat -p ip
コマンドを使用し IP プロトコルについて,不正チェックサム,長さ異常,過度のリダイレクト,およびリソースの問題が原因のパケットの紛失をチェックします。
出力の lost packets due to resource problems フィールドに 0 ではない数があるかどうかを調べてください。
netstat -p ip
コマンドの例は,次のとおりです。
#
netstat -p ip
ip: 259201001 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with header length < data size 0 with data length < header length 25794050 fragments received 0 fragments dropped (duplicate or out of space) 802 fragments dropped after timeout 0 packets forwarded 67381376 packets not forwardable 67381376 link-level broadcasts 0 packets denied access 0 redirects sent 0 packets with unknown or unsupported protocol 170988694 packets consumed here 160039654 total packets generated here 0 lost packets due to resource problems 4964271 total packets reassembled ok 2678389 output packets fragmented ok 14229303 output fragments created 0 packets with special flags set
netstat -id
コマンドを使用して,廃棄された出力パケットのモニタリングを行います。
出力の
Drop
欄に 0 ではない数があるかどうかを調べてください。
インタフェースの 「Drop
」欄に 0 ではない数がある場合は,ifqmaxlen
カーネル変数の値を増やして,パケットの紛失を防ぎます。
この属性の詳細は,6.3.2.9 項を参照してください。
以下の例は,tu1
ネットワーク・インタフェースに 4,221 個の廃棄されたパケットがあることを示しています。
#
netstat -id
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop tu0 1500 Link 00:00:f8:06:0a:b1 0 0 98129 98129 0 0 tu0 1500 DLI none 0 0 98129 98129 0 0 tu1 1500 Link aa:00:04:00:6a:4e 892390 785 814280 68031 93848 4221 tu1 1500 DLI none 892390 785 814280 68031 93848 4221 tu1 1500 orange flume 892390 785 814280 68031 93848 4221 . . .
上のコマンドの出力では,tu0
インタフェースの
Opkts
および
Oerrs
フィールドが同じ数値になっており,イーサネット・ケーブルが接続されていないことを示しています。
また,tu1
インタフェースの
Oerrs
フィールドの値は 68,031 で,高い割合であることを示しています。
netstat -is
コマンドを使用して,詳細なエラー情報を取得してください。
2.4.5.6 再送,順序の不正なパケット,および不正チェックサム
netstat -p tcp
コマンドを使用して,TCP プロトコルの再送,順序の不正なパケット,および不正チェックサムをチェックします。
netstat -p udp
コマンドを使用して,UDP プロトコルの不正チェックサムとソケット・フルを探します。
これらのコマンドの出力のいくつかのフィールドの値を,送信パケットあるいは受信パケットの総数と比較することにより,ネットワークの性能問題を調べることができます。
たとえば,再送パケットと重複肯定応答の割合は,2% 以下なら正常です。 不正チェックサムの割合は,1% 以下なら正常です。
また,embryonic connections dropped
フィールドのエントリが大きな数字を示している場合には,リッスン・キューが小さすぎるか,サーバの性能が低すぎるため,クライアントが要求をキャンセルしていることを意味します。
その他の重要な調査対象フィールドは,completely duplicate packets
,out-of-order packets
,およびdiscarded
です。
netstat -p tcp
コマンドの例は,次のとおりです。
#
netstat -p tcp
tcp: 66776579 packets sent 58018945 data packets (1773864027 bytes) 54447 data packets (132256902 bytes) retransmitted 5079202 ack-only packets (3354381 delayed) 29 URG only packets 7266 window probe packets 2322828 window update packets 1294022 control packets 40166265 packets received 29455895 acks (for 1767211650 bytes) 719524 duplicate acks 0 acks for unsent data 19788741 packets (2952573297 bytes) received in-sequence 123726 completely duplicate packets (9224858 bytes) 2181 packets with some dup. data (67344 bytes duped) 472000 out-of-order packets (85613803 bytes) 1478 packets (926739 bytes) of data after window 43 window probes 201331 window update packets 1373 packets received after close 118 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 448388 connection requests 431873 connection accepts 765040 connections established (including accepts) 896693 connections closed (including 14570 drops) 86298 embryonic connections dropped 25467050 segments updated rtt (of 25608120 attempts) 106020 retransmit timeouts 145 connections dropped by rexmit timeout 6329 persist timeouts 37653 keepalive timeouts 15536 keepalive probes sent 16874 connections dropped by keepalive
上のコマンド出力では,送信された 58,018,945 個のデータ・パケットのうち,54,447 パケットが再送されています。 これは 2% 以下の正常な範囲内にあります。
また,ここでは,29,455,895 の肯定応答のうち,719,524 が重複しており,2% 以下の正常な範囲を少し越えています。
netstat -p udp
コマンドの重要なフィールドには,incomplete headers
,bad data length fields
,bad checksums
,および
full sockets
フィールドがあり,これらは小さな値である必要があります。
no port
フィールドは存在しないポート (たとえば,rwhod
または
routed
のブロードキャスト・パケット) を宛て先として受信したパケットの数です。
このパケットは廃棄されます。
このフィールドが大きな値でも正常であり,性能問題は意味しません。
netstat -p udp
コマンドの実行例は,次のとおりです。
#
netstat -p udp
udp: 144965408 packets sent 217573986 packets received 0 incomplete headers 0 bad data length fields 0 bad checksums 5359 full sockets 28001087 for no port (27996512 broadcasts, 0 multicasts) 0 input packets missed pcb cache
この例では,full sockets
フィールドに 5,359 の値が表示されています。
これは,UDP ソケット・バッファが小さすぎることを意味しています。
2.4.5.7 ルーティングの統計情報
netstat -rs
コマンドを使用すると,ルーティングの統計情報が取得できます。
bad routing redirects
フィールドの値は小さい必要があります。
値が大きいとネットワークに重大な問題があることを意味します。
netstat -rs
コマンドの実行例は,次のとおりです。
#
netstat -rs
routing: 0 bad routing redirects 0 dynamically created routes 0 new gateways due to redirects 1082 destinations found unreachable 0 uses of a wildcard route
netstat -s
コマンドを使用すると,IP,ICMP,IGMP,TCP,および UDP プロトコル層に関連する統計情報が同時に表示できます。
netstat -s
コマンドの実行例は,次のとおりです。
#
netstat -s
ip: 377583120 total packets received 0 bad header checksums 7 with size smaller than minimum 0 with data size < data length 0 with header length < data size 0 with data length < header length 12975385 fragments received 0 fragments dropped (dup or out of space) 3997 fragments dropped after timeout 523667 packets forwarded 108432573 packets not forwardable 0 packets denied access 0 redirects sent 0 packets with unknown or unsupported protocol 259208056 packets consumed here 213176626 total packets generated here 581 lost packets due to resource problems 3556589 total packets reassembled ok 4484231 output packets fragmented ok 18923658 output fragments created 0 packets with special flags set icmp: 4575 calls to icmp_error 0 errors not generated because old ip message was too short 0 errors not generated because old message was icmp Output histogram: echo reply: 586585 destination unreachable: 4575 time stamp reply: 1 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: echo reply: 612979 destination unreachable: 147286 source quench: 10 echo: 586585 router advertisement: 91 time exceeded: 231 time stamp: 1 time stamp reply: 1 address mask request: 7 586586 message responses generated igmp: 0 messages received 0 messages received with too few bytes 0 messages received with bad checksum 0 membership queries received 0 membership queries received with invalid field(s) 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 membership reports sent tcp: 66818923 packets sent 58058082 data packets (1804507309 bytes) 54448 data packets (132259102 bytes) retransmitted 5081656 ack-only packets (3356297 delayed) 29 URG only packets 7271 window probe packets 2323163 window update packets 1294434 control packets 40195436 packets received 29477231 acks (for 1797854515 bytes) 719829 duplicate acks 0 acks for unsent data 19803825 packets (2954660057 bytes) received in-sequence 123763 completely duplicate packets (9225546 bytes) 2181 packets with some dup. data (67344 bytes duped) 472188 out-of-order packets (85660891 bytes) 1479 packets (926739 bytes) of data after window 43 window probes 201512 window update packets 1377 packets received after close 118 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 448558 connection requests 431981 connection accepts 765275 connections established (including accepts) 896982 connections closed (including 14571 drops) 86330 embryonic connections dropped 25482179 segments updated rtt (of 25623298 attempts) 106040 retransmit timeouts 145 connections dropped by rexmit timeout 6329 persist timeouts 37659 keepalive timeouts 15537 keepalive probes sent 16876 connections dropped by keepalive udp: 145045792 packets sent 217665429 packets received 0 incomplete headers 0 bad data length fields 0 bad checksums 5359 full sockets 28004209 for no port (27999634 broadcasts, 0 multicasts) 0 input packets missed pcb cache
2.4.6 ps axlmp を使用した NFS サーバ側の情報収集
NFS サーバ・システムでは,nfsd
デーモンによって,クライアントからの入出力要求をサービスする入出力スレッドが複数生成されます。
サーバでは標準的である複数の並列要求を処理するためには,十分な数のスレッドが構成されることが必要です。
省略時の値である,8 つの UDP スレッドと 8 つの TCP スレッドは,小規模なクライアントに少数のディレクトリをエクスポートするワークステーションでは,十分な値です。
負荷の大きな NFS サーバでは,TCP と UDP に分散される,最大 128 のサーバ・スレッドを構成できます。
サーバ上で NFS サーバ・スレッドのモニタリングを行い,NFS の負荷を処理するためにスレッドを増やす必要があるかどうかを判断します。
サーバ・システムのアイドル入出力スレッドを表示するには,次のコマンドを実行します。
#
/usr/ucb/ps axlmp 0 | grep -v grep | grep -c nfs_udp
#
/usr/ucb/ps axlmp 0 | grep -v grep | grep -c nfs_tcp
スリープ状態とアイドル状態の UDP スレッドと TCP スレッドの数のカウントが表示されます。
スリープ状態の UDP スレッドと TCP スレッドの数が 0,もしくは小さな値の場合,スレッドの数を増やして NFS の性能を改善します。
詳細は,5.4.1 項または
nfsd
(8)2.4.7 nfsiod を使用した NFS クライアント側の情報収集
NFS クライアント・システムでは,nfsiod
デーモンによって,サーバへの非同期入出力要求を処理する入出力スレッドが複数生成されます。
入出力スレッドによって,NFS の読み書き両方の性能が改善できます。
最適の入出力スレッドの数は,多数の要因 (クライアントの書き込み頻度,同時にアクセスするファイルの数,そして NFS サーバの特性など) によって決まります。
小規模なクライアントの場合,省略時の値である 7 スレッドで十分です。
NFS クライアントの負荷が大きい大規模サーバの場合,クライアント・スレッドの数を増やす必要があります。
サーバで NFS クライアント・スレッドのモニタリングを行い,NFS の負荷を処理するためにスレッドを増やす必要があるかどうかを判断します。
クライアント・システムのアイドル入出力スレッドを表示するには,次のコマンドを実行します。
#
ps axlm | grep -v grep | grep -c nfsiod
スリープ状態とアイドル状態の I/O スレッドの数が表示されます。
スリープ状態とアイドル状態の I/O スレッドの数が 0,もしくは小さな値の場合,スレッドの数を増やして NFS の性能を改善します。
詳細は,5.4.2 項または
nfsiod
(8)2.4.8 nfswatch コマンドを使用した NFS サーバの受信ネットワーク・トラフィックのモニタリング
nfswatch
プログラムは,NFS ファイル・サーバのすべての受信ネットワーク・トラフィックをモニタリングし,それを複数のカテゴリに分類します。
各カテゴリ内の受信パケットの数と割合は,持続的に更新される画面に表示されます。
nfswatch
コマンドは通常オプション無しで実行され,役に立つ情報を生成します。
nfswatch
プログラムの実行例は,次のとおりです。
#
/usr/sbin/nfswatch
Interval packets: 628 (network) 626 (to host) 0 (dropped) Total packets: 6309 (network) 6307 (to host) 0 (dropped) Monitoring packets from interface ee0 int pct total unt pct total ND Read 0 0% 0 TCP Packets 0 0% 0 ND Write 0 0% 0 UDP Packets 139 10% 443 NFS Read 2 0% 2 ICMP Packets 1 0% 1 NFS Write 0 0% 0 Routing Control 81 6% 204 NFS Mount 2 0% 3 Address Resolution 109 8% 280 YP/NIS/NIS+ 0 0% 0 Reverse Addr Resol 15 1% 43 RPC Authorization 7 1% 12 Ethernet/FDDI Bdcst 406 30% 1152 Other RPC Packets 4 0% 10 Other Packets 1087 80% 3352 18 NFS Procedures [10 not displayed] more-> Procedure int pct total completed avg(msec) std dev max resp CREATE 0 0% 0 GETATTR 1 50% 1 1 3.90 3.90 GETROOT 0 0% 0 LINK 0 0% 0 LOOKUP 0 0% 0 MKDIR 0 0% 0 NULLPROC 0 0% 0 READ 0 0% 0
注意
nfswatch
コマンドは,NFS バージョン 2.0 でマウントされたファイル・システムについてのみ,データをモニタリングし表示します。
カーネルには
packetfilter
オプションを構成する必要があります。
カーネルの構成後,スーパユーザが
pfconfig
コマンドを使用して無差別モード操作を有効にすれば,どのユーザも
nfswatch
を起動できるようになります。
詳細は,
packetfilter
(7)2.5 その他の性能モニタリング・ツール
システムの性能を継続的にモニタリングするルーチンを設定することができます。 一部のモニタリング・ツールは,重大な問題が発生した場合に警告を行います (たとえば,電子メールで通知する)。 正確な性能情報を得るには,オーバヘッドの少ないモニタリング・ツールを選択することが重要です。
表 2-1
には,性能を継続的にモニタリングするためのツールを示しています。
表 2-1: 継続的な性能モニタリングのツール
名前 | 説明 |
Performance Visualizer |
並列処理システムの重要な構成要素すべての性能を,グラフィカルに表示する。 Performance Visualizer を使用すると,クラスタ内のすべてのメンバ・システムの性能をモニタリングできる。 Performance Visualizer は複数のシステムの性能を同時にモニタリングするため,並列処理アプリケーションがすべてのシステムに与えている影響を調べたり,システム全体でそのアプリケーションのバランスがとれていることを確認できる。 問題の原因が究明できたら,アプリケーションのコードを変更し,Performance Visualizer を使用してその変更による影響を評価できる。 Performance Visualizer は Tru64 UNIX のレイヤード・プロダクトであり,オペレーティング・システムとは別のライセンスが必要。 Performance Visualizer を使用すると,負荷の高いシステムや,使用率の低いリソース,アクティブ・ユーザ,およびビジー状態のプロセスを見つけることもできる。 並列処理システムのすべてのホストを調べるか,個々のホストを調べるかを指定できる。 詳細は,Performance Visualizer のドキュメントを参照。 |
|
稼働中のシステムの各種の性能データを収集し,その情報を表示するか,バイナリ・ファイルに保存する。
|
|
CPU リソースの使用量の多いプロセスのリストなど,システム状態について継続的に報告する。
|
|
システムの平均負荷をヒストグラムで表示し,定期的に更新する。
詳細は,
|
|
LSM 制御下のボリューム,プレックス,サブディスク,およびディスクのアクセス状況を表示する。
|
|
LSM のディスク,ボリューム,およびプレックスの障害をモニタリングし,障害が発生した場合はメールを送信する。 詳細は,9.3 節を参照。 |
プロファイリングを使用すると,アプリケーション・コードの中で実行時間の多くを占める部分を検出できます。 このツールは,カーネルのプロファイリングやデバッグにも使用できます。 性能を改善するには,プログラム内で CPU 時間をたくさん消費している部分のコードの効率化に注目してください。
表 2-2 で,アプリケーションの情報収集で使用するコマンドを説明します。 これらのツールの詳細は,『プログラミング・ガイド』と『Kernel Debugging』を参照してください。
また,アプリケーション・プロファイラ,プロファイリング,最適化,および性能分析の概要が,
prof_intro
(1)表 2-2: アプリケーションのプロファイリング・ツールとデバッグ・ツール