ここでは,システムリソースごとのパフォーマンスの監視方法およびパフォーマンスデータの収集例について説明します。
(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 %フィールドに近い値の場合,プロセスの処理がプロセッサのボトルネックになっているおそれがある。※ |
(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, 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通信 | トラフィックに関連するフィールドでベースライン以上のものがないか監視する。ベースライン以上のフィールドがある場合,次の対策を検討する。
| 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-12 監視ポイント4での監視情報
監視目的 | ボトルネック | 監視方法,対策例 | PI_ADレコードの 監視フィールド |
---|---|---|---|
サイト間ネットワークトラフィックを監視したい。 | サイト間DC通信 | 圧縮後のバイト数がベースライン以上の場合,次の対策を検討する。
| DRA In Total/sec, DRA Out Total/sec |
ゾーン転送 | ゾーン転送のためにサイト間ネットワーク帯域が消費されているかどうか監視する。サイト間ネットワーク帯域が消費されている場合,サイトの統合を検討する。 | Zone Transfer Failure,Zone Transfer Request Received, Zone Transfer SOA Request Sent, Zone Transfer Success | |
レプリケーションによるドメインコントローラー間の通信量の増大を抑えるため,複製の状況を監視したい。 | サイト間DC通信 | トラフィックに関連するフィールドでベースライン以上のものがないか監視する。ベースライン以上のフィールドがある場合,次の対策を検討する。
| 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データベースがディスクアクセスを頻繁に行っていることが挙げられます。この場合,メモリーのキャッシュやバッファへの割り当てを見直すことによって問題を解決できます。
表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秒当たりに開かれたデータベーステーブルの数。 |
表1-14 データベースのログ書き込み状況を監視するフィールド
フィールド | 説明 |
---|---|
Log Record Stalls/sec | ログバッファに空きがないために追加できない1秒当たりのログレコードの数。 |
Log Threads Waiting | データベースの更新を完了させるために,ログバッファ上のデータがログファイルに書き込まれるのを待機しているスレッドの数。 |
Log Writes/sec | ログバッファ上のデータがログファイルに書き込まれる1秒当たりの回数。 |
・特定のドメインにログオンが集中する場合
Active Directoryによって使用されている現在のセッション数を確認したい場合は,次のフィールドを確認してください。
表1-15 現在のセッション数を監視するフィールド
フィールド | 説明 |
---|---|
AB Client Sessions | 接続されているアドレス帳クライアントセッションの数。 |
LDAP Client Sessions | 接続されているLDAPクライアントセッションの数。 |
・サイト内のネットワーク負荷が高い場合
サイト内のネットワーク負荷が高い場合,Active Directoryがサイト内でレプリケーションを大量に行っていることが原因となっている場合があります。サイト内のレプリケーションのトラフィックを監視するフィールドを次に示します。
表1-16 サイト内のレプリケーションのトラフィックを監視するフィールド
フィールド | 監視対象 | 説明 |
---|---|---|
DRA In Not Compress | 入力方向のレプリケーション | 圧縮されていないデータのバイト数(入力量)。 |
DRA In Not Compress/sec | 圧縮されていないデータの1秒当たりのバイト数(入力頻度)。 | |
DRA Out Not Compress | 出力方向のレプリケーション | 圧縮されていないデータのバイト数(出力量)。 |
DRA Out Not Compress/sec | 圧縮されていないデータの1秒当たりのバイト数(出力頻度)。 |
・サイト間のネットワーク負荷が高い場合
サイト間のネットワーク負荷が高い場合,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秒当たりのバイト数(出力頻度)。 |
(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ポートのうちリッスン中のポート数。 |
@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
Product Name=PFM-Agent for Platform (Windows)
FormVer=0001
tt ks lr lr lr
TCP jp1ps05 15 3 12
"C:¥Program Files¥HITACHI¥jp1pc¥agtt¥agent¥jpcuser¥jpcuser" PI_UPIB
-file D:¥homework¥userdata.tcp
(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製品が導入されていないホストのデータ収集の流れ
図中の番号に従って処理の流れを説明します。複数のホストのパフォーマンスデータを収集する場合は,同様の手順をホストごとに実行してください。
copy D:¥homework¥userdata.tcp F:¥nethome¥userdata.tcp
"C:¥Program Files¥HITACHI¥jp1pc¥agtt¥agent¥jpcuser¥jpcuser" PI_UPIB
-file ユーザー作成データ1 -file ユーザー作成データ2 -file ユーザー作成データ3