JP1/Performance Management - Agent Option for Platform（Windows(R)用）

[目次][用語][索引][前へ][次へ]

1.3.2　パフォーマンス監視のしかた

ここでは，システムリソースごとのパフォーマンスの監視方法およびパフォーマンスデータの収集例について説明します。

＜この項の構成＞
(1)　プロセッサ
(2)　メモリー
(3)　ディスク
(4)　ネットワーク
(5)　プロセスおよびサービス
(6)　イベントログ
(7)　Active Directoryの監視例
(8)　利用ポート情報の収集例
(9)　PFM製品が導入されていない複数のホストからのパフォーマンスデータの収集例

(1)　プロセッサ

プロセッサのパフォーマンスを監視する方法について説明します。

(a)　概要

プロセッサのパフォーマンス情報を監視すれば，システム全体のパフォーマンスの傾向を把握できます。

Windowsでは，次の図に示すように，ユーザーモードとカーネルモードという，2種類のプロセッサアクセスモードでプロセスを実行しています。Windowsのアーキテクチャー概要図を次に示します。

図1-1　Windowsのアーキテクチャー概要図

[図データ]

さらに，キュー数で監視する方法が考えられます。

プロセスなどのジョブは，OSによってスケジューリングされCPUを割り当てられて実行されます。キュー数は，CPUの割り当てられるのを待っているジョブの数です。このため，システム全体の負荷が高くなると，キュー数が増大する傾向にあります。

ソリューションセットでは，CPU Usageアラームや，CPU Status（Multi-Agent）レポートなどを提供しています。

ソリューションセットで用意されているプロセッサのパフォーマンスをさらに詳細に監視するには，プロセッサごとのプロセッサ使用率，プロセスごとのプロセッサ使用率，プロセッサのキュー数，およびハードウェアからのプロセッサ割り込みなどを監視する方法が考えられます。

関連するレコードとフィールドを次の表に示します。

表1-1　プロセッサに関連する主なフィールド

使用レコード 使用フィールド 値の見方（例）
PI_PCSR CPU % 各プロセッサのCPU使用率。継続してしきい値（通常85%を目安とする）以上の値の場合，プロセッサがシステムのボトルネックになっているおそれがある。※
Privileged CPU % カーネルモードで実行した各プロセッサのCPU使用率。PI_PCSRレコードCPU %フィールドが継続してしきい値以上の場合，特定のアプリケーションプロセス（サービス含む）またはシステムプロセス（サービス含む）に問題があるおそれがある。※
User CPU % ユーザーモードで実行した各プロセッサのCPU使用率。
PI_PCSRレコードCPU %フィールドが継続してしきい値以上の場合，特定のアプリケーションプロセス（サービス含む）に問題があるおそれがある。※
PI_SVRQ Queue Length キューの要求数。継続してしきい値（2）以上の値の場合，プロセッサの混雑を示す。
PI Processor Queue Length
CPU % プロセッサの使用率（%）。プロセッサが非アイドル状態のスレッドを実行した経過時間の割合。マルチプロセッサ環境にかかわらず最大値は「100」で表示される。
Privileged CPU % カーネルモードで実行したCPU使用率。PIレコードCPU %フィールドが継続してしきい値以上の場合，特定のアプリケーションプロセス（サービス含む）またはシステムプロセス（サービス含む）に問題があるおそれがある。
User CPU % ユーザーモードで実行したのCPU使用率。PIレコードCPU %フィールドが継続してしきい値以上の場合，特定のアプリケーションプロセス（サービス含む）に問題があるおそれがある。
Total Interrupts/sec 1秒当たりのハードウェア割り込みを処理した数。システムの活動状況がない状態で，このフィールドが大幅に増加している場合，ハードウェア割り込みでプロセッサに負荷を掛ける低速なデバイスが存在するなどのハードウェアの問題を示すおそれがある。
PI_PCSR Interrupts/sec プロセッサごとの1秒当たりのハードウェア割り込みを処理した数。PIレコードのTotal Interrupts/secフィールドをプロセッサごとに監視する場合に使用する。

注※
各プロセッサを監視する場合に使用します。

マルチプロセッサ環境の場合，システムのCPU使用率は全CPUの使用率の平均値で表されます。このため，CPUごとのCPU使用率を確認してください。

また，ボトルネックの原因になっているプロセスを特定するには，プロセスごとのCPU使用率を確認してください。

関連するレコードとフィールドを次の表に示します。

表1-2　プロセッサに関連する主なフィールド（マルチプロセッサ環境）

使用レコード 使用フィールド 値の見方（例）
PD_PDI CPU % 各プロセスのCPU使用率。継続してしきい値以上の値の場合，プロセスがプロセッサのボトルネックになっているおそれがある。※
Privileged CPU % カーネルモードで実行した各プロセスのCPU使用率。CPU %フィールドが継続してしきい値以上の値で，さらに
Privileged CPU %がCPU %フィールドに近い値の場合，プロセスが発行しているAPIがプロセッサのボトルネックになっているおそれがある。※
User CPU % ユーザーモードで実行した各プロセスのCPU使用率。CPU %フィールドが継続してしきい値以上の値で，さらにUser CPU %がCPU %フィールドに近い値の場合，プロセスの処理がプロセッサのボトルネックになっているおそれがある。※

注※
マルチプロセッサ環境では，「プロセッサ数＊100%」を最大値とした使用率が表示されます。

(b)　監視方法

・プロセッサ使用率を監視したい

プロセッサ使用率は，ソリューションセットで提供しているCPU Usageアラームを使用することで，システム全体のプロセッサ使用率を監視できます。

プロセッサの使用率（PIレコードCPU %フィールド）は，プロセッサの負荷状況を監視できます。詳細については，「1.3.3(1)(a)　ソリューションセット」を参照してください。

・プロセッサの混雑を監視したい

プロセッサの混雑（キュー数）を監視することで，プロセッサ使用率と同様，プロセッサの負荷状況を監視できます。

プロセッサの混雑は，プロセッサ使用率とあわせて監視すると効果的です。

プロセッサ使用率とキュー数（PI_SVRQレコードのQueue Lengthフィールド）がしきい値以上の値を表示している場合，プロセッサが混雑していると考えられます。

また，キュー数（PIレコードのProcessor Queue Lengthフィールド）は2程度がしきい値となります。この値が10以上の値を表示している場合，システムの限界を超えているおそれがあります。プロセッサをアップグレードするか，プロセッサを追加するなどの対策の目安となります。

定義例については，「1.3.3(1)(b)　ソリューションセット以外の定義例」を参照してください。

・プロセッサ使用率が高いプロセスを確認したい

プロセッサ使用率とプロセッサの混雑を監視して，ボトルネックになっているおそれがあると判断した場合，過度にプロセッサを使用しているプロセス（PD_PDIレコードCPU %フィールド）を，リアルタイムレポートで見つけます。

プロセスに問題がない場合，限界を超えるシステム環境のため，プロセッサをアップグレードするか，プロセッサを追加するなどの目安となります。

定義例については，「1.3.3(1)(b)　ソリューションセット以外の定義例」を参照してください。

(2)　メモリー

メモリーのパフォーマンスを監視する方法について説明します。

(a)　概要

メモリーを監視することによって，物理メモリーの不足を検出したり，プロセスの不正な動作を検出したりできます。

メモリーは，次の図のように，物理メモリーとページングファイルから構成されています。物理メモリーやページングファイルが十分でないからといってメモリーが不足しているだけとは限りません。このため，メモリー使用量に加えて，ページングやページフォルトなどのメモリー利用効率もあわせて監視してください。

メモリー空間の構成を次の図に示します。

図1-2　メモリー空間概念図

[図データ]

物理メモリーが不足している場合，システム全体のパフォーマンスの低下を招きます。また，プログラムが参照するメモリー領域は，一定時間以上アクセスされないとページングファイル上に退避され，必要なタイミングで物理メモリーにロードされます。このようにして，少ない物理メモリーを有効利用します。しかし，ページングファイルへのアクセスは物理メモリーのアクセスに比べて，大幅に低速です。このため，メモリー利用効率が悪くページングやページフォルトが大量に発生している場合，システム処理の大幅な遅延が発生している状態を意味します。

ページングなどは，標準的な処理でも行われています。このため，システム安定稼働時のベースラインを測定し，適切なしきい値を決定してください。

ソリューションセットでは，Available Memoryアラームを提供しています。さらに詳細な情報を参照するには，次のような関連するレコードとフィールドを参考にしてください。

表1-3　メモリーに関連する主なフィールド

使用レコード 使用フィールド 値の見方（例）
PI Pages/sec ページングした1秒当たりの操作数。継続してしきい値（5）以上の場合，メモリーがシステムのボトルネックになっているおそれがある。ただし，一時的にしきい値以上の場合，20までは許容範囲になることがある。
Page Faults/sec ページフォルトが発生した1秒当たりの数。継続してしきい値（5）以上の場合，メモリーがボトルネックになっているおそれがある。
Data Map Hits % ページングが発生しないで，ファイルシステムキャッシュにページをマッピングした要求の割合。低い値が継続している場合，メモリーがボトルネックになっているおそれがある。
Total Physical Mem Mbytes 物理メモリーの容量。
Available Mbytes 物理メモリーの空き容量。
Used Physical Mem Mbytes 物理メモリーの使用量。
% Physical Mem 物理メモリーの使用率。
Commit Limit Mbytes 仮想メモリーの容量。
Non Committed Mbytes 仮想メモリーの空き容量。
Committed Mbytes 仮想メモリーの使用量。継続してしきい値（PI レコードTotal Physical Mem Mbytesフィールド）以上の場合，より多くの物理メモリーが必要な可能性がある。
% Committed Bytes in Use 仮想メモリーの使用率。継続してしきい値（システムの負荷状態で判断）以上の場合，ページングファイルの拡張が必要な可能性がある。
PD_PAGF % Usage ページングファイルの使用率。継続してしきい値（システムの負荷状態で判断）以上の場合，ページングファイルの拡張が必要な可能性がある。

システムのメモリー不足は，メモリー不足が原因であるとは限りません。プログラムの不具合が原因で，メモリーが不足する場合もあります。プロセスごとのメモリー使用量を監視すれば，これらの原因を切り分けることができます。不当にメモリーを占有していたり，メモリー使用量が単調に増加していたりするプロセスがある場合，そのプロセスのプログラムに不具合があると判断できます。

特定のプロセスに関するメモリー使用量を参照するには，次のレコードとフィールドを参考にしてください。

表1-4　プロセスごとのメモリーに関連する主なフィールド

使用レコード 使用フィールド 値の見方（例）
PI Pool Nonpaged Bytes ページアウトできない物理メモリー使用量。サーバの活動状況が増加していない状態で，このフィールドが増加し続けている場合，メモリーリークを発生させているプロセスが存在しているおそれがある。
PD_PDI Page Faults/sec ページフォルトが発生した1秒当たりの数。プロセスのページフォルトからボトルネックを発生させているプロセスを洗い出す。
Pool Nonpaged Kbytes 各種メモリー，ハンドル使用量。このフィールド（メモリー，ハンドル数）が増加し続けている場合，プロセスがメモリーリークを発生させているおそれがある。
Pool Paged Kbytes
Working Set Kbytes
Page File Kbytes
Private Kbytes
Handle Count

(b)　監視方法

・物理メモリーの未使用サイズを監視したい

物理メモリーの未使用サイズ（PIレコードAvailable Mbytesフィールド）は，ソリューションセットで提供しているAvailable Memoryアラームで監視できます。

詳細については，「1.3.3(2)(a)　ソリューションセット」を参照してください。

・仮想メモリーの使用状況を監視したい

仮想メモリーの使用状況は，メモリーの増設が必要かどうかの目安となります。

メモリーの使用状況が一時的に高い場合でも，継続的な高負荷状態ではないときは，パフォーマンスの低下を許容できる可能性があるため，仮想メモリーの負荷状況と合わせて監視すると効果的です。

使用している仮想メモリー使用量（PIレコードCommitted Mbytesフィールド）が，物理メモリー総量（PIレコード Total Physical Mem Mbytesフィールド）以上の場合，より多くのメモリーが必要な可能性があります。

定義例については，「1.3.3(2)(b)　ソリューションセット以外の定義例」を参照してください。

・仮想メモリーの負荷状況を監視したい

仮想メモリーの負荷状況は，メモリーの増設が必要かどうかの目安となります。

メモリーの使用状況が一時的に高い場合でも，継続的な高負荷状態ではないときは，パフォーマンスの低下を許容できる可能性があるため，仮想メモリーの使用状況と合わせて監視すると効果的です。

ページフォルト数（PIレコードPage Faults/secフィールド）がしきい値以上の場合，アプリケーションが確保するメモリー量に対して，サーバに割り当てられているメモリーが不足しているおそれがあります。

ページング数（PIレコード Pages/secフィールド）がしきい値以上の場合，物理メモリーが不足している可能性があります。

定義例については，「1.3.3(2)(b)　ソリューションセット以外の定義例」を参照してください。

・メモリーリークが発生していないか確認したい

メモリーリークが発生すると余分なメモリーを消費するため，システム全体が正しく動作しません。履歴レポートの折れ線グラフで，非ページプールのメモリー量（PIレコードPool Nonpaged Bytesフィールド）が単調に増加していないか確認することで，メモリーリークが発生していないか確認できます。

起動プロセスの増減がない状態で，非ページプールのメモリー量（PIレコードPool Nonpaged Bytesフィールド）が単調に増加している場合，メモリーリークを発生させているプロセスが存在するおそれがあります。

定義例については，「1.3.3(2)(b)　ソリューションセット以外の定義例」を参照してください。

・プロセスのメモリー使用量を監視したい

メモリーリークが発生していると判断した場合，原因となるプロセスを特定してください。

サーバの活動状況が増加していない状態で，各プロセスのメモリー使用量（PD_PDIレコードWorking Set Kbytesフィールドなど）をリアルタイムレポートで数分〜数十分程度監視し，表示されている折れ線グラフで増加し続けているプロセスがないか確認します。

メモリーリークを発生させているプロセスを特定し，製造元に問い合わせるなどの対策の目安となります。

定義例については，「1.3.3(2)(b)　ソリューションセット以外の定義例」を参照してください。

(3)　ディスク

ディスクのパフォーマンスを監視する方法について説明します。

(a)　概要

ディスクを監視すれば，ディスク資源の不足などを検出したり，ディスクによるボトルネックを把握したりできます。また，継続的にディスクを監視すれば，ディスク容量の使用量の増加傾向を把握し，システム構成決定や拡張するなどのタイミングを把握できます。

ディスクはプログラムやプログラムが参照するデータなどを保存しています。このため，ディスク容量が不足してくると，データが消失するなどの問題が発生するだけでなく，システムの応答速度が低下します。

プログラムからディスクのデータを入出力する場合，実行中に休止（応答を待っている）状態になることがあります。これは，ディスクがボトルネックになり始めていることを示します。

ディスクのボトルネックが原因で，プロセスの応答速度の低下などさまざまな性能劣化を引き起こす場合があります。そのため，ディスクに関連する性能劣化が発生していないことを確認するのは重要な作業です。

ディスクにボトルネックが存在すると思われる場合，はじめに，ディスクの断片化が発生していないことを確認してください。次に，不正なファイルなどによってディスクが消費されていないかを確認し，十分な空き容量が確保されていることを確認する必要があります。不正なファイルが存在する場合，不正にファイルなどを作成したプログラムを特定し，対処する必要があります。

ソリューションセットでは，Disk Spaceアラームを提供しています。さらに詳細な情報については，次のレコードとフィールドを参照してください。

表1-5　ディスクに関連する主なフィールド

使用レコード 使用フィールド 値の見方（例）
PI_LOGD，
PI_PHYD		 % Disk Time ディスクのビジー率。継続してしきい値（50%以上または100%に近い）の場合，ディスクへの負荷が高いことを示す。
Current Disk Queue Length キューの要求数。継続してしきい値（3）以上の場合，ディスクが混雑していることを示す。
Avg Disk Bytes/Xfer ディスク間で転送された1回当たりのバイト数。転送サイズが大きいほどシステムは効果的に稼働していることを示す。
Disk Bytes/sec ディスク間で転送された1秒当たりのバイト数。転送サイズが大きいほどシステムは効果的に稼働していることを示す。
PI_LOGD % Free Space ディスクの空き領域率。少ない場合，ディスク容量が不足していることを示す。
Free Mbytes ディスクの未使用領域。少ない場合，ディスク容量が不足していることを示す。

(b)　監視方法

・論理ディスクの空き容量率を監視したい

論理ディスクの空き容量率は，ソリューションセットで提供しているDisk Spaceアラームを使用することで，監視できます。

詳細については，「1.3.3(3)(a)　ソリューションセット」を参照してください。

論理ディスクの空き容量率（PI_LOGDレコード% Free Spaceフィールド）がしきい値以下の場合，断片化されたファイルをディスクデフラグツールで最適化する際，支障をきたすことがあります。

また，論理ディスクの空き容量率がしきい値以下の場合でも，全容量が大きいディスクの場合，許容できる容量の可能性もあります。このため，論理ディスクの空き容量と合わせて監視すると効果的です。

・論理ディスクの空き容量を監視したい

論理ディスクの空き領域をアラームで監視すると，ディスク容量不足を効果的に監視できます。

論理ディスクの空き領域（PI_LOGDレコードFree Mbytesフィールド）がしきい値以下になった場合，不要ファイルの削除，ファイル圧縮，ディスク増設などの対策の目安となります。

定義例については，「1.3.3(3)(b)　ソリューションセット以外の定義例」を参照してください。

・ディスクのビジー率を監視したい

ディスクのビジー率は，過度なページング（プロセスによるページの読み取り，または書き込み）が発生していないかをアラームで監視できます。

ディスクのビジー率（PI_PHYDまたはPI_LOGDレコード% Disk Timeフィールド）が継続的にしきい値以上の場合，ディスク要求を発生させているプロセスを調べ，プロセスの分散処理をするなどの対策の目安となります。

ディスクの混雑と合わせて監視すると効果的です。

定義例については，「1.3.3(3)(b)　ソリューションセット以外の定義例」を参照してください。

・ディスクの混雑を監視したい

ディスクの混雑は，過度なI/O要求が発生していないかをアラームで監視できます。

ディスクの混雑（PI_PHYDまたはPI_LOGDレコードCurrent Disk Queue Lengthフィールド）が継続的にしきい値以上の場合，ディスク要求を発生させているプロセスを調べ，プロセスの分散処理をするなどの対策の目安となります。

ディスクのビジー率と合わせて監視すると効果的です。

定義例については，「1.3.3(3)(b)　ソリューションセット以外の定義例」を参照してください。

(4)　ネットワーク

ネットワークのパフォーマンスを監視する方法について説明します。

(a)　概要

ネットワークの情報を監視すれば，システムが提供している機能の応答速度を確認できます。

ネットワークのデータの送受信量などを継続的に監視すれば，ネットワークの構成決定や拡張などを計画的に行えます。

関連するレコードとフィールドを次の表に示します。

表1-6　ネットワークに関連する主なフィールド

使用レコード 使用フィールド 値の見方（例）
PI_NETI Bytes Total/sec 送受信された1秒当たりのデータ量。常にNICを使用し送受信している環境で，しきい値（低い値[高い程良い]）以下の値が数多く発生した場合，NICがボトルネックになっているおそれがある。※
Bytes Sent/sec 送信された1秒当たりのデータ量。常にNICを使用し送信している環境で，しきい値（低い値[高い程良い]）以下の値が数多く発生した場合，NICがボトルネックになっているおそれがある。※
PI Bytes Rcvd/sec 受信された1秒当たりのデータ量。サーバがネットワークから受信したバイト数をネットワークカードの総帯域幅性能と比較し，帯域幅（ネットワークで一定時間内に転送できるデータの量）50%以上の場合，ネットワーク接続がボトルネックになっているおそれがある。

注※
高い値の場合，多量の転送に成功したこと示します。

(b)　監視方法

・ネットワークインターフェースカードの帯域幅（一定時間内に転送できるデータの量）を超えるデータ受信がないか監視したい

ネットワークインターフェースカードの帯域幅をアラームで監視すると，ネットワークの送受信データ量を監視できます。

データ量が継続的にしきい値以上の場合，ネットワークインターフェースカードまたは物理ネットワークをアップグレードする目安となります。

定義例については，「1.3.3(4)(b)　ソリューションセット以外の定義例」を参照してください。

(5)　プロセスおよびサービス

プロセスおよびサービスのパフォーマンスを監視する方法について説明します。

(a)　概要

システムは，個々のプロセスやサービスによって提供されています。このため，プロセスやサービスの稼働状況を把握することは，システムの安定運用に欠かせません。

システムの機能を提供するプロセスやサービスが異常終了した場合，運用システムが停止し重大な影響が発生します。このため，プロセスの生成，消滅，および起動状況やサービスの起動状況を監視し，早急に異常を検知し対策を立てることが必要です。

PFM - Agent for Platformでは，情報収集のタイミングでプロセスを監視しています。このため，プロセスの存在確認をしている場合でも，プロセスが消滅したタイミングではなく，PFM - Agent for Platform が情報を収集したタイミングでプロセスの消滅が検知されることに注意してください。

プロセスおよびサービスを監視するためのレコードとフィールドを次の表に示します。

表1-7　プロセスおよびサービスに関連する主なフィールド

使用レコード 使用フィールド 値の見方（例）
PI_WGRP Process Count プロセス数。しきい値（起動している必要があるプロセス数）以下の場合，プロセスが停止していることを示す。※
PD_PDI Program プロセス名。レコード収集されない場合，プロセスが停止していることを示す。
PD_SVC Service Name サービス名および起動状態。アプリケーションサービス（プロセス）が起動中（RUNNING）以外の場合，サービスが停止していることを示す。
Display Name
State

注※
収集データ追加ユーティリティでの設定が必要です。

(b)　監視方法

・プロセスの消滅を監視したい

プロセスが異常終了した場合，運用システムが停止し重大な影響が発生します。早急に復旧させるために，プロセスの消滅をアラームで監視できます。

定義例については，「1.3.3(5)(b)　ソリューションセット以外の定義例」を参照してください。

・プロセスの生成を監視したい

プロセスの生成は，アプリケーション単位での監視やスケジュールされたプロセスの状況など，運用システムが正しく動作しているかどうかをアラームで監視できます。

収集データ追加ユーティリティのワークグループの設定とPI_WGRPレコードを使用することで，プロセスの生成や消滅，同一名称のプロセス数，アプリケーション単位のプロセス数，およびユーザーごとのプロセス起動数などさまざまな監視を行えます。

定義例については，「1.3.3(5)(b)　ソリューションセット以外の定義例」を参照してください。

・サービスの停止を監視したい

サービスが異常終了した場合，運用システムが停止し重大な影響が発生します。

早急に復旧させるために，サービスの起動状況をアラームで監視できます。

定義例については，「1.3.3(5)(b)　ソリューションセット以外の定義例」を参照してください。

(6)　イベントログ

イベントログのパフォーマンスを監視する方法について説明します。

(a)　概要

OSやアプリケーションは，「エラー，警告，情報」などの情報をイベントビューアに出力しています。このため，イベントビューアのイベントログを監視することで，OSの不具合やプロセスの異常な動作を検知でき，早急に復旧できます。

イベントログを監視するためのレコードとフィールドを次の表に示します。

表1-8　イベントログに関連する主なフィールド

使用レコード 使用フィールド 値の見方（例）
PD_ELOG Log Name イベントログの種類。Application，Security，Systemなどがある。
Event Type Name イベントタイプの識別子名。異常（Error），警告（Warning）などがある。
Source Name 作成したアプリケーション名など。生成したアプリケーションを特定する場合に利用する。
Event ID イベントID。アプリケーションのイベントログを一意に特定する場合に利用する。
Description イベントログの説明。イベントログの詳細な情報が出力されている。

(b)　監視方法

・イベントログに出力されたすべてのエラーおよび警告を監視したい

イベントログに出力されたエラーおよび警告をアラームで監視できます。

定義例については，「1.3.3(6)(b)　ソリューションセット以外の定義例」を参照してください。

・MSCSクラスタの動作を監視したい

MSCSが出力しているイベントログをアラームで監視できます。

定義例については，「1.3.3(6)(b)　ソリューションセット以外の定義例」を参照してください。

(7)　Active Directoryの監視例

PFM - Agent for PlatformでActive Directoryを監視する方法および監視例について説明します。

(a)　Active Directory監視情報

PFM - Agent for Platform 08-11以降のバージョンでは，Active Directory監視情報を収集するActive Directory Overview（PI_AD）レコードを使用できます。PI_ADレコードを参照することで，レプリケーションの実行状況・結果，およびセッションの接続状況を監視できます。これによって，Active Directoryが正常に動作していることを確認したり，負荷を確認したりできます。

ここでは，Active Directoryの構成と監視目的に応じた監視情報について説明します。

Active Directoryの構成を次の図に示します。

図1-3　Active Directoryの構成

[図データ]

図中の番号に沿って，監視目的に応じた監視情報について説明します。

表1-9　監視ポイント1での監視情報

監視目的 ボトルネック 監視方法，対策例 PI_ADレコードの
監視フィールド
不正なログオン試行が行われていないか監視したい。 ユーザーログオン 認証要求数が現在のログオンユーザー数より大幅に多い場合，不正ログオンが試行されている（ログオンに失敗し続けているユーザーがいる）おそれがある。不正ログオンのおそれがある場合，不正ログオンの対策を行う。 Kerberos Authentications，
NTLM Authentications，
LDAP Client Sessions
ユーザーからの要求を，複数のドメインコントローラーに分散させて，パフォーマンスの低下を防ぎたい。 各ドメインコントローラーへの接続セッション数を取得して，ログオン数を比較する。比較結果を基に，ドメインコントローラーに所属するユーザーの配分を見直し，負荷を分散させる。 LDAP Client Sessions

表1-10　監視ポイント2での監視情報

監視目的 ボトルネック 監視方法，対策例 PI_ADレコードの
監視フィールド
Active Directoryのパフォーマンスに大きな影響を与えるデータベースを監視したい。 Active Directoryデータベース用キャッシュ 次の場合，キャッシュに割り当てるメモリーを増やす。
  • 「Cache % Hit」フィールド，「Table Open Cache % Hit」フィールドの値がベースライン以下の場合。
  • 「Cache Page Fault Stalls/sec」フィールド，「Table Open Cache Misses/sec」フィールドの値がベースライン以上の場合。
 Cache % Hit，
Cache Page Fault Stalls/sec，
Cache Page Faults/sec，
Cache Size，
Table Open Cache % Hit，
Table Open Cache Hits/sec，
Table Open Cache Misses/sec，
Table Opens/sec
Active Directoryデータベース用ログバッファ 「Log Record Stalls/sec」フィールドの値がベースライン以上の場合，ログバッファに割り当てるメモリーを増やす。 Log Record Stalls/sec，
Log Threads Waiting，
Log Writes/sec

表1-11　監視ポイント3での監視情報

監視目的 ボトルネック 監視方法，対策例 PI_ADレコードの
監視フィールド
レプリケーションによるドメインコントローラー間の通信量の増大を抑えるため，複製の状況を監視したい。 サイト内DC通信 トラフィックに関連するフィールドでベースライン以上のものがないか監視する。ベースライン以上のフィールドがある場合，次の対策を検討する。
  • ネットワークの速度を速いものに変更する。
  • サイト内のレプリケーションのスケジュールをCPU使用率の低い時間帯に変更する。
 DRA In Total/sec，
DRA Out Total/sec
ファイル複製によるActive Directory機能のパフォーマンスの低下，フォルダ競合によるファイルの喪失および損傷を防ぎたい。 「DRA Sync Requests Made」フィールドの値から「DRA Sync Requests Successful」フィールドの値を引いた値が単調増加している場合，Active Directory機能が低下しているおそれがある。※1この場合，サイト内のレプリケーションのスケジュールをCPU使用率の低い時間帯に変更する。 DRA In Total/sec，
DRA Out Total/sec
サイト内の大量のネットワークトラフィックが発生するのを防ぎたい。 「SAM Password Changes/sec」フィールドがベースライン以上の場合，パスワード変更要求がネットワークトラフィックのボトルネックになっているおそれがある。※2この場合，ドメインコントローラーに所属するユーザーの配分を見直し，負荷を分散させる。 SAM Password Changes/sec

注※1
ファイル複製の要求待ちが多い場合，レスポンスが低下していると言えます。DRA関連フィールドを監視し，「DRA Sync Requests Made」フィールドの値から「DRA Sync Requests Successful」フィールドの値を引いた値が単調増加していない場合は，ファイルの複製に失敗していないため正常と言えます。

注※2
パスワードの変更要求数が多い場合，ネットワークトラフィックが大量に発生します。「SAM Password Changes/sec」フィールドの値を監視し，ユーザーが事前に見込んだ1秒当たりのパスワード変更数より低い場合は問題ありません。

　

表1-12　監視ポイント4での監視情報

監視目的 ボトルネック 監視方法，対策例 PI_ADレコードの
監視フィールド
サイト間ネットワークトラフィックを監視したい。 サイト間DC通信 圧縮後のバイト数がベースライン以上の場合，次の対策を検討する。
  • サイト間レプリケーションのスケジュールをCPU使用率の低い時間帯に変更する。
  • サイトを統合する。
 DRA In Total/sec，
DRA Out Total/sec
ゾーン転送 ゾーン転送のためにサイト間ネットワーク帯域が消費されているかどうか監視する。サイト間ネットワーク帯域が消費されている場合，サイトの統合を検討する。 Zone Transfer Failure，Zone Transfer Request Received，
Zone Transfer SOA Request Sent，
Zone Transfer Success
レプリケーションによるドメインコントローラー間の通信量の増大を抑えるため，複製の状況を監視したい。 サイト間DC通信 トラフィックに関連するフィールドでベースライン以上のものがないか監視する。ベースライン以上のフィールドがある場合，次の対策を検討する。
  • ネットワークの速度を速いものに変更する。
  • サイト間レプリケーションのスケジュールをCPU使用率の低い時間帯に変更する。
 DRA In Total/sec，
DRA Out Total/sec

(b)　Active Directory監視情報の収集に必要な前提条件

Active Directoryのパフォーマンスデータを取得するには，Active Directoryをインストールしてください。Active Directoryが有効でない環境では，Active Directory監視情報を取得できません。インストール方法については「5.　レコード」の「Active Directoryのインストール方法」を参照してください。

(c)　Active Directory監視方法

Active Directoryが正常に動作しているかどうか判断するために，まず，基本となる幾つかのパフォーマンス情報のアラームを作成して常に監視します。これらのアラームが異常または警告状態となった場合に，詳細なレポートを解析して問題を解決します。基本となるパフォーマンス情報の監視について次に説明します。

・Active Directoryが動作しているドメインコントローラーの稼働状況を監視する

Active Directoryが動作しているサーバの基本パフォーマンスは，Active Directory自体のパフォーマンスに大きく影響します。Active Directoryが動作しているサーバの稼働状況を監視するためのアラームおよびレポートを次に示します。

・Active Directory固有のパフォーマンス情報を監視する

Active Directory固有のパフォーマンス情報を監視するためのPI_ADレコードのフィールドを次に示します。

(d)　Active Directoryの監視例

Active Directoryに関係するパフォーマンスの低下がある場合，PI_ADレコードを収集して監視することで，問題解決の糸口をつかめます。次の現象が発生している場合に，ボトルネックを特定するための監視項目を示します。

上記の現象が発生している場合の監視例を次に示します。なお，記載している監視例は凡例であり，ユーザーの環境によって変動します。しきい値などの設定はユーザーの環境に合わせてください。

・ドメインコントローラーの負荷が継続的に高い場合

ドメインコントローラーの負荷が高くなる原因として，Active Directoryデータベースがディスクアクセスを頻繁に行っていることが挙げられます。この場合，メモリーのキャッシュやバッファへの割り当てを見直すことによって問題を解決できます。

Active Directoryデータベースキャッシュの監視
Active Directoryデータベースでは，適切なキャッシュサイズを設定することで，ディスク上のファイル操作を発生させることなくレコードを操作させることができます。このキャッシュ利用率を監視することで，データベースアクセスのパフォーマンスを上げるようキャッシュを調整できます。データベースのキャッシュ利用率を監視するフィールドを次に示します。

表1-13　データベースのキャッシュ利用率を監視するフィールド

フィールド 説明
Cache % Hit データベースキャッシュによって，ファイル操作を発生させることなく実行されたデータベースファイルページの要求の割合。
Cache Page Fault Stalls/sec データベースキャッシュから割り当てできるページがないためにサービスを受けられない1秒当たりのページフォールトの数。
Cache Page Faults/sec データベースキャッシュマネージャが，データベースキャッシュから新しいページを割り当てるために必要な1秒当たりのデータベースファイルページの要求数。
Cache Size データベースキャッシュマネージャがデータベースファイルから頻繁に使用される情報を保持するのに使用するシステムメモリーの容量。
Table Open Cache % Hit キャッシュしたスキーマ情報を使用して開かれたデータベーステーブルの割合。
Table Open Cache Hits/sec キャッシュしたスキーマ情報を使用して開かれたデータベーステーブルの1秒当たりの数。
Table Open Cache Misses/sec キャッシュしたスキーマ情報を使用しないで開かれたデータベーステーブルの1秒当たりの数。
Table Opens/sec 1秒当たりに開かれたデータベーステーブルの数。

監視例
次の条件を満たす場合，キャッシュ容量の不足が原因でパフォーマンスが低下していると想定されます。
  • Cache % Hit，Table Open Cache % Hitがベースラインを下回っている。
  • Cache Page Fault Stalls/secがベースラインを上回っている。

対策例
Active Directoryデータベースのキャッシュに割り当てるメモリーを増やしてください。

データベースのログ書き込み状況の監視
データベースログのバッファの使用状況を監視して，ログバッファの容量を適切に調整することで，ログ書き込みのための待ち時間を減少できます。「Active Directoryデータベースキャッシュの監視」と異なり，こちらはログバッファのパフォーマンス情報です。

表1-14　データベースのログ書き込み状況を監視するフィールド

フィールド 説明
Log Record Stalls/sec ログバッファに空きがないために追加できない1秒当たりのログレコードの数。
Log Threads Waiting データベースの更新を完了させるために，ログバッファ上のデータがログファイルに書き込まれるのを待機しているスレッドの数。
Log Writes/sec ログバッファ上のデータがログファイルに書き込まれる1秒当たりの回数。

監視例
次の条件を満たす場合，ログバッファの容量不足が原因でパフォーマンスが低下していると想定されます。
  • Log Record Stalls/secがベースラインを上回っている。

対策例
ログバッファに割り当てるメモリーを増やしてください。

・特定のドメインにログオンが集中する場合

Active Directoryによって使用されている現在のセッション数を確認したい場合は，次のフィールドを確認してください。

表1-15　現在のセッション数を監視するフィールド

フィールド 説明
AB Client Sessions 接続されているアドレス帳クライアントセッションの数。
LDAP Client Sessions 接続されているLDAPクライアントセッションの数。

監視例
次の条件を満たす場合，特定のドメインにログオンが集中していると想定されます。
  • LDAP Client Sessionsがベースラインを上回っている。

対策例
  • 各ドメインコントローラーに割り当てるユーザーの数を均等にしてください。
  • ドメインコントローラーを増やすなど，ユーザーの数を分散させる対処をしてください。

・サイト内のネットワーク負荷が高い場合

サイト内のネットワーク負荷が高い場合，Active Directoryがサイト内でレプリケーションを大量に行っていることが原因となっている場合があります。サイト内のレプリケーションのトラフィックを監視するフィールドを次に示します。

表1-16　サイト内のレプリケーションのトラフィックを監視するフィールド

フィールド 監視対象 説明
DRA In Not Compress 入力方向のレプリケーション 圧縮されていないデータのバイト数（入力量）。
DRA In Not Compress/sec 圧縮されていないデータの1秒当たりのバイト数（入力頻度）。
DRA Out Not Compress 出力方向のレプリケーション 圧縮されていないデータのバイト数（出力量）。
DRA Out Not Compress/sec 圧縮されていないデータの1秒当たりのバイト数（出力頻度）。

監視例
次の条件を満たす場合，サイト内のレプリケーションのトラフィックが原因で，サイト内のネットワーク負荷が高くなっていると想定されます。
  • DRA In Not Compress/sec，DRA Out Not Compress/secがベースラインを上回っている。

対策例
ドメインコントローラーを増やすなど，負荷を分散させてください。

・サイト間のネットワーク負荷が高い場合

サイト間のネットワーク負荷が高い場合，Active Directoryがサイト間レプリケーションを大量に行っていることが原因となっている場合があります。サイト間レプリケーションでは通信を圧縮して行う点がサイト内のレプリケーションと異なります。レプリケーションの動作自体は変わりません。サイト間レプリケーションのトラフィックを監視するフィールドを次に示します。

表1-17　サイト間レプリケーションのトラフィックを監視するフィールド

フィールド 監視対象 説明
DRA In After Compress 入力方向のレプリケーション 圧縮後データのバイト数（入力量）。
DRA In After Compress/sec 圧縮後データの1秒当たりのバイト数（入力頻度）。
DRA In Before Compress 圧縮前データのバイト数（入力量）。
DRA In Before Compress/sec 圧縮前データの1秒当たりのバイト数（入力頻度）。
DRA Out After Compress 出力方向のレプリケーション 圧縮後データのバイト数（出力量）。
DRA Out After Compress/sec 圧縮後データの1秒当たりのバイト数（出力頻度）。
DRA Out Before Compress 圧縮前データのバイト数（出力量）。
DRA Out Before Compress/sec 圧縮前データの1秒当たりのバイト数（出力頻度）。

監視例
次の条件を満たす場合，サイト間レプリケーションのトラフィックが原因で，サイト間のネットワーク負荷が高くなっていると想定されます。
  • DRA In After Compress/sec，DRA In Before Compress/sec，DRA Out After Compress/sec，DRA Out Before Compress/secがベースラインを上回っている。

対策例
  • サイト間レプリケーションのスケジュールをCPU使用率の低い時間帯に設定してください。
  • サイトの統合を検討して，サイト間通信を減らしてください。

　

ポイント
レプリケーションはデータベース管理システムが持つ負荷分散機能の一つです。データベースの複製をネットワーク上に複数配置し，回線やマシンの負荷を軽減する機能です。Active Directoryではレプリケーション機能が使用できます。これによってマシンの負荷を分散させるとともに，高速なディレクトリサービスを提供しています。
レプリケーションはActive Directoryを含むディレクトリサービスで重要な位置にあります。レプリケーションのトラフィックを監視することによって，現在の負荷を知ることができ，必要な処置の判断ができます。
Active Directoryは，サイト内では高速で信頼性のあるネットワーク接続を想定した動作を行います。そのため，サイト内レプリケーションの実行時にデータは圧縮されません。これによって圧縮処理によるオーバーヘッドを抑えています。
一方，サイト間のドメインコントローラー間でレプリケーションを行う場合，通常のサイト間通信では距離が離れているためコストがかかります。このため，サイト間レプリケーションを行う場合にはデータを圧縮します。

(8)　利用ポート情報の収集例

PFM - Agent for Platformでは，ユーザーがテキストファイルに出力した独自のパフォーマンスデータ（ユーザー作成データ）を，PFM - Agent for Platformが提供するレコードに格納できる形式（ユーザーデータファイル）に変換する機能を提供しています。ユーザー独自のパフォーマンスデータの詳細については，「3.2.6　ユーザー独自のパフォーマンスデータ収集の設定」を参照してください。

ここでは，ユーザー独自のパフォーマンスデータとして利用ポート情報をPI_UPIBレコードに収集する例を示します。利用ポート情報は，次の表に示す形式で格納するものとします。

表1-18　ユーザー作成データのフォーマット

オプション 値
tt "TCP"。
ks ホスト名。
lr ホストが持つTCPポートの総数。
lr ホストが持つTCPポートのうち現在アクティブなポート数。
lr ホストが持つTCPポートのうちリッスン中のポート数。

  1. 利用ポート情報を収集するためのバッチを作成する。
    この例では，利用ポート情報を収集するためにバッチを利用します。バッチの作成例を次に示します。

    Windows 2003でのバッチの作成例（D:\homework\sample.bat）
    @echo off
echo Product Name=PFM-Agent for Platform (Windows) > D:\homework\userdata.tcp
echo FormVer=0001 >> D:\homework\userdata.tcp
echo tt ks lr lr lr >> D:\homework\userdata.tcp
hostname > D:\homework\userdata.tmp
netstat -ap tcp | find "TCP" /C >> D:\homework\userdata.tmp
netstat -ap tcp | find "ESTABLISHED" /C >> D:\homework\userdata.tmp
netstat -ap tcp | find "LISTENING" /C >> D:\homework\userdata.tmp
(
set /p ks=
set /p lr1=
set /p lr2=
set /p lr3=
) < D:\homework\userdata.tmp
del D:\homework\userdata.tmp
echo TCP %ks% %lr1% %lr2% %lr3% >> D:\homework\userdata.tcp
    注意
    ここで紹介するバッチはWindows 2003での作成例のため，ほかのOSでは正しく動作しないおそれがあります。また，環境によってはWindows 2003上でも動作しないことがあるため注意してください。

  2. 手順1で作成したバッチを実行する。
    バッチの実行結果として作成されるユーザー作成データを次に示します。

    ユーザー作成データ（D:\homework\userdata.tcp）
    Product Name=PFM-Agent for Platform (Windows)
FormVer=0001
tt ks lr lr lr
TCP jp1ps05 15 3 12

  3. 手順2で作成されたユーザー作成データをユーザーデータファイルへ変換する。
    ユーザー作成データをユーザーデータファイルへ変換するコマンド（jpcuserコマンド）の実行例を次に示します。

    jpcuserコマンドの実行例
    "C:\Program Files\HITACHI\jp1pc\agtt\agent\jpcuser\jpcuser" PI_UPIB 
-file D:\homework\userdata.tcp

  4. 手順3で出力されたユーザーデータファイルをPFM - Agent for Platformで収集する。
    PFM - Agent for Platformがレコードを収集するタイミングで，ユーザーデータファイルの内容がユーザーレコードに格納されます。

(9)　PFM製品が導入されていない複数のホストからのパフォーマンスデータの収集例

PFM製品が導入されていないホスト固有のパフォーマンスデータを，PFM - Agent for Platformのユーザー作成データ収集機能を使って収集できます。また，複数のホストのパフォーマンスデータを一つのユーザーデータファイルに変換することで，同時に複数のホストの状態を監視することもできます。この場合，PFM製品が導入されていないそれぞれのホストでユーザー作成データを作成するために，バッチなどのスクリプトを準備する必要があります。ここでは，PFM製品が導入されていないホストのパフォーマンスデータを収集し，PFM - Agent for Platformのレコード情報として出力するまでの例を示します。

(a)　収集データ

ここでは「1.3.2(8)　利用ポート情報の収集例」で作成したユーザー作成データを使用して情報を取得する例を示します。

(b)　前提条件

PFM製品が導入されていない複数のホストからパフォーマンスデータを収集するための前提条件を次に示します。

(c)　データ収集の手順

PFM製品が導入されていないホストのデータ収集の流れを次の図に示します。

図1-4　PFM製品が導入されていないホストのデータ収集の流れ

[図データ]

図中の番号に従って処理の流れを説明します。複数のホストのパフォーマンスデータを収集する場合は，同様の手順をホストごとに実行してください。

  1. PFM製品が導入されていないホストでユーザー作成データを作成する。
    パフォーマンスデータを収集するスクリプトを実行して，ユーザー作成データを作成します。ここでは「1.3.2(8)　利用ポート情報の収集例」で作成したユーザー作成データを使用します。

  2. リモートホスト間でファイルをコピーする。
    手順1で作成したユーザー作成データを，PFM製品が導入されているホストにコピーします。ここではネットワークドライブの割り当てによってホスト間で共有している領域「F:\nethome\」にユーザー作成データをコピーします。copyコマンドの例を次に示します。

    copyコマンドの例
    copy D:\homework\userdata.tcp F:\nethome\userdata.tcp
    注意
    複数のホストのユーザー作成データを収集する場合は，ファイル名が重複しないようにしてください。ファイル名が重複している場合，ファイルをコピーするときに上書きするおそれがあります。

  3. PFM製品が導入されているホストでjpcuserコマンドを実行する。
    PFM製品が導入されているホストでjpcuserコマンドを実行して，手順2でコピーしたユーザー作成データをユーザーデータファイルに変換します。手順1および2を実行したPFM未導入ホストのユーザー作成データを，一つのユーザーデータファイルに変換する例を次に示します。

    jpcuserコマンドの例
    "C:\Program Files\HITACHI\jp1pc\agtt\agent\jpcuser\jpcuser" PI_UPIB 
-file ユーザー作成データ1 -file ユーザー作成データ2 -file ユーザー作成データ3

  4. PFM製品が導入されているホストでレコードデータを収集する。
    手順3で出力されたユーザーデータファイルの内容を，PFM製品が導入されているホストでレコードデータとして収集します。

[目次][前へ][次へ]

[他社商品名称に関する表示]

All Rights Reserved. Copyright (C) 2006, 2008, Hitachi, Ltd.