2    システム情報と性能情報の取得

性能上の問題点を見つけたり,どの分野で性能が低下しているかを把握するには,性能について広範囲の情報を収集しなければなりません。

症状が明白な場合や,性能上の問題点が明示的に通知される場合もあります。 たとえば,アプリケーションが完了するまでの時間が長かったり,システムのリソース不足を示すメッセージがコンソールに表示される場合があります。 このような場合以外は,問題点や性能不足は明白ではなく,システム性能をモニタリングして初めて検出できます。

システム性能情報を取得するために使用できる各種のコマンドとユーティリティがあります。 統計情報はさまざまな条件のもとで取得することが重要です。 データのセットを比較することが,性能問題の診断に役に立ちます。

たとえば,アプリケーションがシステム性能にどのように影響を与えているのか調べるには,アプリケーションを実行していない状態で性能の統計情報を取得し,その後,アプリケーションを実行してから,同じ統計情報を取得します。 異なるデータのセットを比較すれば,アプリケーションのメモリ,CPU,またはディスク入出力の消費量がわかります。

さらに,正確な性能情報を得るには,アプリケーション処理の複数の段階で情報を収集しなければなりません。 たとえば,ある段階では入出力を多用し,別の段階では CPU を多用するアプリケーションが考えられます。

この章では,以下の内容について説明します。

性能上の問題点を見つけたり,どの分野で性能が低下しているかを把握したら,適切な解決方法を見つけることができます。 システム性能の改善のために,アプリケーション別にチューニングを行う方法は,Part 2を参照してください。 構成要素別にチューニングを行う方法は,Part 3を参照してください。

2.1    性能問題の解決のための方法論的アプローチ

性能問題を診断するための推奨手順は 5 つあります。 最初に,性能と可用性に関する用語と概念を,十分に理解しておく必要があります。 詳細は,第 1 章 を参照してください。

また,アプリケーションがシステム・リソースをどのように使用しているかについても,理解している必要があります。 すべての構成とチューニングのガイドラインが,すべてのタイプの作業負荷に適するわけではないからです。 たとえば,アプリケーションはメモリ多用型なのか,CPU 多用型なのかを調べる必要があります。 あるいは,ディスク操作が多いのか,ネットワーク操作が多いのかを調べる必要があります。 構成に適したリソース・モデルについて詳細は,1.8 節を参照してください。

性能問題を診断するには,以下の手順を実行します。

  1. 最初に,システムのハードウェア構成を理解する必要があります。 ハードウェア構成要素を調べて,管理するには,hwmgr ユーティリティを使用します。 詳細は,1.1 節または2.3.1 項を参照してください。

  2. システム性能のチューニングに使用するオペレーティング・システムのパラメータとカーネル属性を分析してから,sys_check ユーティリティを実行します。 このツールは性能問題を診断するために使用できます。 詳細は,2.3.3 項を参照してください。

  3. ソフトウェアの構成エラーを確認し,認識しておきます。 sys_check を使用して,性能問題を診断することもできます。 システム・イベントの情報の取得方法は,2.2 節を参照してください。

  4. どのようなタイプのアプリケーションを使用しているか確認し,アプリケーションを,Oracle,ネットワーク・ファイル・システム,またはインターネット・サーバに分類します。 システムをアプリケーション別にチューニングする場合は,以下の章を参照してください。

  5. ボトルネック,つまり性能低下の原因となっているシステム・リソースを調べます。 以下の情報をプロットして,性能問題を判断します。

    collect コマンドを使用して,システムに負荷がかかっている時間,または性能問題が現れている時間の性能データを取得します。 性能情報を取得した後,collgui グラフィカル・インタフェースを使用して,データをプロットします。 collgui の使用方法は,2.3.2.2 項を参照してください。 作業負荷に適したリソース・モデルについては,1.8 節を参照してください。

2.2    システム・イベントについての情報の取得

システム・イベントを継続的にモニタリングし,重大な問題が発生した場合に警告を発するルーチンを設定してください。 定期的にイベントやログ・ファイルを調べると,性能や可用性に影響が現われる前に問題点を修正できます。 また,性能上の問題の診断が容易になります。

システム・イベントのログは,システム・イベント・ロギング機能と,バイナリ・イベント・ロギング機能によって取得されます。 システム・イベント・ロギング機能では,syslog 関数を使用して,ASCII 形式でイベントのログを取得します。 syslogd デーモンは,各種のカーネル,コマンド,ユーティリティ,アプリケーション・プログラムで取得されたログ・メッセージを収集します。 そしてこのデーモンは,/etc/syslog.conf イベント・ロギング構成ファイルで指定されているとおりに,メッセージをローカル・ファイルに書き込むか,メッセージをリモート・システムに転送します。 これらの ASCII ログ・ファイルを定期的にモニタリングして,性能情報を入手してください。

バイナリ・イベント・ロギング機能では,カーネル内のハードウェア・イベントとソフトウェア・イベントを検出し,詳細情報のログをバイナリ形式のレコードで記録します。 バイナリ・イベント・ロギング機能では,binlogd デーモンを使用して,各種のイベント・ログ・レコードを収集します。 そしてこのデーモンは,省略時の構成ファイル /etc/binlog.conf で指定されているとおりに,レコードをローカル・ファイルに書き込むか,リモート・システムに転送します。

バイナリ・イベント・ログ・ファイルは,次の方法で調査できます。

また,クラッシュ・ダンプ・サポートをシステムに構成してください。 性能上の重大な問題によってシステム・クラッシュが引き起こされることがあります。 クラッシュ・ダンプ分析ツールを使用すると,性能上の問題点を診断するのに役立ちます。

イベント・ログとクラッシュ・ダンプについての詳細は,『システム管理ガイド』を参照してください。

2.2.1    イベント・マネージャの使用

イベント・マネージャ (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

階層表示コマンドは,システム階層に入っている現在登録済みのハードウェア構成要素を表示します。 フラグ・ステータスを持った構成要素は,コマンド出力の中の以下のコードで区別できます。

これらのコードについての説明は, 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

オプション文字は,以下のサブシステムを表わしています。

プロセス・データを収集する場合は,-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 グラフィカル・インタフェースを使用して,情報をプロットするには,以下の手順を実行します。

  1. collgui をデバッグ・モードで実行します。

    >> collgui -d "collect datafile"
    

  2. サブシステムを選択し,[Display] をクリックします。

  3. collgui を起動したシェルに戻ります。 collgui によって,/var/tmp ディレクトリが作成されたことがわかります。 ファイル名は,collgui.xxxx です。 ここで,xxxx は整数です。 データ・ファイル (collgui.xxxx) は,Excel にエクスポートすることができます。 これを Windows システムへコピーします。

  4. Windows システムで Excel を起動し,collgui.xxxx を開きます。 「ファイルの種類」フィールドでは,「すべてのファイル (*.*)」を選択する必要があります。

  5. Excel 2000 で,「テキストファイルウィザード」が開きます。

  6. Excel 2000 で,「データのファイル形式」で [コンマやタブなどの区切り文字によってフィールドごとに区切られたデータ] を選択し,[次へ] を選択します。

  7. Excel 2000 で,「区切り文字」として [タブ] と [スペース] を選択します。 そして,[次へ] を選択します。

  8. 「データのプレビュー」ペインで,シフト・キーを使用してインポートする列を選択し,[完了] を選択します。

  9. ワークシートに列が表示されます。

cflit collect フィルタを使用して情報をプロットするには,以下の手順を実行します。

  1. cfilt を使用して,データ・ファイルを作成します。 たとえば,データの処理に使用されている system timephysical memory,そして「Single CPU」フィールドに待ち時間,user+system time を表示するように選択するには,次のコマンドを実行します。

    cfilt -f "collect datafile" 'sin:WAIT:USER+SYS' 'pro:Systim#:RSS#'
    > /var/tmp/collgui.xxxx
    

    collgui データ・ファイルを Windows システムにコピーします。

  2. 上述の 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 ファイルが作成されます。 コマンド行で指定できるオプションを,次に示します。

詳細は, sys_check(8) を参照してください。

2.4    情報収集用の補助的なツール

以下に示すユーティリティが,性能情報収集用の補助的なツールです。

システム情報の収集

ネットワーク情報の収集

2.4.1    lockinfo ユーティリティを使用したロック統計情報の収集

lockinfo ユーティリティを使用すると,カーネル SMP ロックのロック統計情報の収集と表示が行われます。 このユーティリティはデータを収集するために,/dev/lockdev 擬似ドライバを使用します。 ロック統計情報は,generic サブシステムの lockmode 属性が,2 (省略時の値),3,または 4 のときに収集されます。

lockinfo で統計情報を収集するには,以下の手順を実行します。

  1. システムに作業負荷を発生させ,それが安定状態になるまで待ちます。

  2. sleep コマンドを指定し,適当な秒数を cmd_args に指定して lockinfo を起動します。 これにより,lockinfosleep コマンドを実行している間の統計情報を収集します。

  3. 最初の一連の結果に基づき,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 を使用して統計情報を収集するには,以下の手順を実行します。

  1. システムの作業負荷を発生させ,それが安定状態になるまで待ちます。

  2. sleep コマンドを指定し,適当な秒数を cmd_args に指定して sched_stat を起動します。 これにより,sched_statsleep コマンドを実行したときの統計情報を収集します。

たとえば,次のコマンドを実行すると,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 で出力される情報のほとんどは,チューニングの可能性を調べるために使用されるのではなく,ネットワークのハードウェアまたはソフトウェアの障害を診断するために使用されます。 障害の診断方法についての詳細は,『ネットワーク管理ガイド:接続編』を参照してください。

各種のコマンド・オプションで生成される出力についての詳細は, 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  
. 
. 
.

2.4.5.2    デバイス・ドライバのエラー

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 桁の数字である必要があります。

2.4.5.3    メモリの利用率

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 packetsout-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 headersbad data length fieldsbad 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

2.4.5.8    プロトコルの統計情報

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 のドキュメントを参照。

monitor

稼働中のシステムの各種の性能データを収集し,その情報を表示するか,バイナリ・ファイルに保存する。 monitor ユーティリティは,Tru64 UNIX のフリーウェア CD-ROM で提供。 詳細は,http://h30097.www3.hp.com/demos/ossc/ を参照。

top

CPU リソースの使用量の多いプロセスのリストなど,システム状態について継続的に報告する。 top コマンドは,Tru64 UNIX のフリーウェア CD-ROM で提供。 詳細は,ftp://eecs.nwu.edu/pub/top を参照。

xload

システムの平均負荷をヒストグラムで表示し,定期的に更新する。 詳細は, xload(1X) を参照。

volstat

LSM 制御下のボリューム,プレックス,サブディスク,およびディスクのアクセス状況を表示する。 volstat ユーティリティは,ブート時または統計情報のリセット時以降の LSM オブジェクトの動作レベルを反映した統計情報を報告する。 詳細は,9.3 節を参照。

volwatch

LSM のディスク,ボリューム,およびプレックスの障害をモニタリングし,障害が発生した場合はメールを送信する。 詳細は,9.3 節を参照。

2.6    プロファイリング情報とデバッグ情報の収集

プロファイリングを使用すると,アプリケーション・コードの中で実行時間の多くを占める部分を検出できます。 このツールは,カーネルのプロファイリングやデバッグにも使用できます。 性能を改善するには,プログラム内で CPU 時間をたくさん消費している部分のコードの効率化に注目してください。

表 2-2 で,アプリケーションの情報収集で使用するコマンドを説明します。 これらのツールの詳細は,『プログラミング・ガイド』と『Kernel Debugging』を参照してください。

また,アプリケーション・プロファイラ,プロファイリング,最適化,および性能分析の概要が, prof_intro(1) に記載されています。

表 2-2:  アプリケーションのプロファイリング・ツールとデバッグ・ツール

名前 用途 説明

atom

アプリケーションのプロファイルを作成する。

パッケージ化されたツールのセット (thirdhiprof,および pixie) で,アプリケーションのプロファイリングとデバッグ用の測定を行うために使用される。 atom ツールキットには,コマンド・インタフェースと測定ルーチンの集合も付いており,アプリケーション測定用のカスタマイズ・ツールを作成できる。 詳細は,『プログラミング・ガイド』と atom(1) を参照。

third

メモリへのアクセスをチェックしてアプリケーションのメモリ・リークを検出する。

atom ツールを使用して,実行可能オブジェクトと共有オブジェクトにコードを追加して,C あるいは C++ で作成されたプログラムの実行時のメモリ・アクセス・チェックとメモリ・リーク検出を行う。 Third Degree ツールは,参照先のライブラリを含む,プログラム全体の測定を行う。 詳細は, third(1) を参照。

hiprof

アプリケーションのプロシージャ実行時間のプロファイルを作成する。

atom ベースのプログラム・プロファイリング・ツール。 指定したプロシージャでの実行時間を示すフラット・プロファイルと,指定したプロシージャおよびそれから呼び出されるすべてのプロシージャの実行時間を示す階層プロファイルを作成する。

hiprof ツールは,プログラム・カウンタ (PC) のサンプリングではなく,コードの計測によって統計情報を収集する。 通常,出力ファイルのフィルタおよびマージ処理とプロファイル・レポートのフォーマッティングには,gprof コマンドが使用される。 詳細は, hiprof(1) を参照。

pixie

アプリケーション内の基本ブロックのプロファイルを作成する。

プログラム内の各命令の実行回数を示すプロファイルを作成する。 この情報は,テーブル形式で報告することもできるが,後で,C コンパイラに -feedback-om または -cord オプションを指定して,最適化の自動指示に使用することもできる ( cc(1) 参照)。

pixie プロファイラは実行可能プログラムを読み込み,基本ブロックに分割して,各基本ブロックの実行回数をカウントするコードを付加した同等のプログラムを出力する。

また,pixie ユーティリティは,各基本ブロックのアドレスが格納されたファイルも生成する。 pixie が生成したプログラムを実行すると,基本ブロックのカウントを含むファイルが生成される。 prof および pixstats コマンドは,これらのファイルの分析に使用できる。 詳細は, pixie(1) を参照。

prof

プロファイル・データを分析する。

プロファイル・データを分析して,コードの中で CPU 時間が最もかかっている部分と経過時間が長い場所を示す統計情報を作成する (たとえば,ルーチン・レベル,基本ブロック・レベル,命令レベル)。

prof コマンドは,プロファイリング・ツールの kprofileuprofile,または pixie で生成された 1 つまたは複数のデータ・ファイルを入力として使用する。 また,prof コマンドは,cc などのコンパイラに -p スイッチを指定してリンクされたプログラムが生成したプロファイル・データ・ファイルにも使用できる。

prof が生成した情報を使用すると,ソース・コードを最適化するために,どの部分に注目すればよいか判断できる。 詳細は, prof(1) を参照。

gprof

プロファイル・データを分析し,アプリケーション内のプロシージャ呼び出し情報とプログラム・カウンタを統計的にサンプリングした情報を表示する。

プロファイル・データを分析し,プロシージャ呼び出し情報の収集とプログラム・カウンタ (PC) の統計的なサンプリングにより,どのルーチンが最も多く呼び出されたか,またルーチンの呼び出し元が何かを判断できるようにする。

gprof ツールはルーチンの CPU 使用状況のフラット・プロファイルを生成する。 プログラムのグラフィカルな実行プロファイルを作成するために,このツールでは,cc -pg コマンドでコンパイルしたプログラムが生成した PC サンプリング・プロファイルのデータか,または atom -tool hiprof コマンドで変更したプログラムが生成した計測プロファイルのデータを使用する。 詳細は, gprof(1) を参照。

uprofile

アプリケーション内のユーザ・コードのプロファイルを作成する。

Alpha チップの性能カウンタを用いてユーザ・コードのプロファイルを作成する。 uprofile ツールを使用すると,プログラムの実行可能部分のみをプロファイリングできる。 uprofile ツールは,シェアード・ライブラリの情報は収集しない。 このツールで収集したデータは,prof コマンドで処理できる。 詳細は,『Kernel Debugging』または uprofile(1) を参照。

kprofile

動作中のカーネルのプログラム・カウンタ・プロファイルを作成する。

Alpha チップの性能カウンタを用いて,動作中のカーネルのプロファイリングを行う。 このツールで収集した性能データは,prof コマンドで分析する。 詳細は, kprofile(1) を参照。

Visual Threads

マルチスレッド・アプリケーション内でのボトルネックと性能上の問題を把握する。

このツールでは,マルチスレッド・アプリケーションの分析と改良ができる。 Visual Threads を使用すると,ボトルネックと性能の問題を把握し,スレッド関連のロジックの潜在的な問題をデバッグすることができる。 Visual Threads は規則に基づいた分析と,統計機能および視覚化の技法を使用する。 Visual Threads は,Developers' Toolkit for Tru64 UNIX の一部としてライセンスされている。

dbx

動作中のカーネル,プログラム,とクラッシュ・ダンプのデバッグ,およびカーネル変数の調査と一時的な変更をする。

C,Fortran,Pascal,アセンブラ言語,およびマシン語のソース・レベル・デバッグに使用する。 dbx を使用すると,クラッシュ・ダンプの分析,プログラム・オブジェクト内の問題点のトレース (ソース・コード・レベルまたはマシン・コード・レベル),プログラムの実行の制御,プログラム・ロジックや制御フローのトレース,およびメモリ領域のモニタリングができる。

カーネルのデバッグ,デバッグ情報のないイメージのデバッグ,メモリ内容の調査,マルチスレッドのデバッグ,ユーザ・コードとアプリケーションの分析,カーネル・データ構造体の値およびフォーマットの表示,一部のカーネル変数の値の一時的な変更を行うには,dbx を使用する。 詳細は, dbx(8) を参照。

kdbx

動作中のカーネルおよびクラッシュ・ダンプのデバッグをする。

動作中のカーネルやクラッシュ・ダンプを調査できる。 kdbx デバッガは dbx デバッガのフロントエンドであり,カーネル・コードをデバッグし,カーネル・データを読み取り可能な形式で表示するために使用する。 このデバッガは拡張およびカスタマイズが可能で,カーネル・デバッグのニーズに合ったコマンドを作成することができる。

拡張機能を使用して,リソースの使用状況 (たとえば,CPU の使用状況) をチェックすることもできる。 詳細は, kdbx(8) を参照。

ladebug

カーネルおよびアプリケーションのデバッグ

プログラムとカーネルをデバッグし,プログラムの実行時エラーの検出を手助けする。 ladebug シンボリック・デバッガは dbx の代替デバッガであり,コマンド行とグラフィカル・ユーザ・インタフェースの両方で,マルチスレッド・プログラムのデバッグができる。 詳細は,『Ladebug Debugger Manual』および ladebug(1) を参照。

lsof

オープン・ファイルを表示する。

実行中のプロセスが現在オープンしているファイルに関する情報を表示する。 lsof は, または Tru64 UNIX のフリーウェア CD-ROM から入手可能。