本書を使用した場合のトラブルは対処できません。参考としてご利用ください。
Windows サーバ
パフォーマンスモニター カウンタ解説
〜 各カウンタの意味・監視意図と推奨しきい値 〜
1. はじめに
本書は、Windows Server のパフォーマンスモニター(Performance Monitor、perfmon.exe)で取得できる主要なパフォーマンスカウンタについて、各カウンタの意味・監視意図・推奨しきい値を体系的にまとめた資料である。
サーバのサイジング、性能検証、日常の性能監視、障害時のボトルネック切り分けにおいて、どのカウンタを、何の目的で、どの閾値を基準に観察すべきかを整理することを目的とする。
1.1 オブジェクトとカウンタの関係
パフォーマンスモニターのメトリクスは以下の階層で構成される。
- パフォーマンスオブジェクト(例: Processor、Memory、LogicalDisk)
- カウンタ(例:
% Processor Time、Available MBytes) - インスタンス(例:
_Total、0、1、C:、D:)
複数インスタンスを持つオブジェクト(Processor、LogicalDisk、Network Interface など)では、_Total と個別インスタンスの両方を確認することが重要である。_Total のみを見ると、特定のインスタンスで発生しているボトルネックを見逃す場合がある。
1.2 本書の見方
各カウンタは以下の 3 項目で説明する。
- カウンタ名: 日本語版 Windows での名称、および英語名
- 意味・意図: カウンタが何を表し、何を判断するために使うか
- 目安・閾値: 一般的に注意が必要とされる値(環境により異なる)
2. プロセッサ(CPU)関連 CPU
CPU の使用状況、負荷、コンテキストスイッチなどを確認するカウンタ群。CPU ボトルネックの切り分けに使用する。
2.1 Processor オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Processor Time (Processor(_Total)) |
CPU 全体の使用率。アイドル以外のスレッド実行時間の割合を示す。サーバ全体の CPU 負荷を把握する最も基本的な指標。 | 継続的に 80% 超過で警戒 90% 超過で要対処 |
| % User Time | ユーザーモード(アプリケーション)での CPU 実行時間の割合。アプリケーション処理がどの程度 CPU を消費しているかを示す。 | % Privileged Time との比率を確認 |
| % Privileged Time | カーネルモード(OS 処理)での CPU 実行時間の割合。ドライバ処理や I/O、システムコールの負荷を示す。 | 継続的に 30% 超過は調査対象 ドライバ異常の可能性 |
| % Interrupt Time | ハードウェア割り込み処理に費やされた CPU 時間の割合。NIC・ディスク・その他デバイスからの割り込み負荷を示す。 | 継続的に 10〜15% 超過で ハードウェア異常を疑う |
| % Idle Time | CPU がアイドル状態であった時間の割合。100 − % Processor Time に近い値となる。 | 常時 20% 未満なら CPU 不足 |
| Interrupts/sec | 1 秒あたりの割り込み回数。デバイスドライバやハードウェアからの割り込み頻度を示す。 | 急激な増加はドライバ異常・ ハードウェア不良の兆候 |
2.2 System オブジェクト(CPU 関連)
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Processor Queue Length | 実行可能状態で CPU 割り当てを待っているスレッドの数。CPU が処理しきれていない負荷の蓄積を示す。 | 論理コア数 × 2 を超える状態が 継続する場合は CPU ボトルネック |
| Context Switches/sec | 1 秒あたりのスレッド切り替え回数。多すぎるとコンテキストスイッチ自体が CPU を消費する。 | 論理コア 1 つあたり 5,000〜10,000 超で要調査 |
| System Calls/sec | 1 秒あたりのシステムコール回数。アプリケーションが OS 機能をどの程度要求しているかの指標。 | ベースライン比較で判断 |
| Threads | システム全体のスレッド数。異常なスレッド増加はリーク・プロセス暴走の兆候。 | ベースラインからの 急増を監視 |
| Processes | システム上で動作しているプロセス数。 | ベースラインからの 急増を監視 |
切り分けのポイント
- % Processor Time が高く Processor Queue Length も長い → CPU コア数不足、スケールアップ / アウトを検討
- % Processor Time は高くないが Processor Queue Length が長い → プロセスの CPU 親和性設定や優先度設定を確認
- % Privileged Time が異常に高い → ドライバ、ウイルス対策ソフト、ファイルシステムフィルタを疑う
- % Interrupt Time が高い → NIC、HBA、RAID コントローラのファームウェア・ドライバを確認
3. メモリ関連 Memory
物理メモリ、仮想メモリ、ページング、キャッシュの状況を確認する。メモリ不足はディスク I/O の増加を誘発し、システム全体の性能劣化を引き起こす。
3.1 Memory オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Available MBytes (Available Bytes) |
即時に割り当て可能な物理メモリ量(MB)。空きメモリ + スタンバイメモリの合計。メモリ不足判定の第一指標。 | 総物理メモリの 10% 未満 または 500MB 未満で警戒 |
| Committed Bytes | プロセスが実際に確保(コミット)している仮想メモリの総量。物理 + ページファイル上の予約領域を含む。 | Commit Limit の 80% 超で警戒 |
| Commit Limit | システム全体でコミット可能な仮想メモリの上限値。物理メモリ + ページファイル合計。 | Committed Bytes との比率で ページファイル枯渇を判断 |
| % Committed Bytes In Use | Committed Bytes / Commit Limit の割合。仮想メモリ全体の逼迫度を示す。 | 継続的に 80% 超で要増設 90% 超で緊急対処 |
| Pages/sec | ハードページフォールトの発生頻度(1 秒あたり)。ディスクから物理メモリへのページ読み込み・書き出し回数。メモリ不足によるディスクアクセスの指標。 | 継続的に 1,000 超で メモリ不足の可能性 |
| Pages Input/sec | ハードページフォールトでディスクから読み込まれたページ数。プログラム・データが物理メモリ外に追い出されている証拠。 | ディスク I/O 負荷と連動して 急増する場合は要注意 |
| Pages Output/sec | 物理メモリからページファイルへ書き出されたページ数。書き込みが多いとメモリ不足が進行中。 | 継続的な増加はメモリ不足 |
| Page Faults/sec | ソフト+ハードページフォールト合計。ソフトは性能影響小、ハードは大きな影響。Pages/sec と併せて判断。 | 単独では判断材料にならない |
| Pool Paged Bytes | ページング可能なカーネルプールの使用量。ドライバ・カーネル構造体が使用。リークするとじわじわ枯渇する。 | 時系列で継続増加なら ドライバリークを疑う |
| Pool Nonpaged Bytes | ページング不可能なカーネルプールの使用量。常に物理メモリに存在する領域。 | 継続増加はカーネルリーク |
| Cache Bytes | システムファイルキャッシュに使われている物理メモリ量。ファイル I/O 性能に寄与。 | メモリ不足時に縮小する |
| Free System Page Table Entries | 未使用のシステムページテーブルエントリ(PTE)数。枯渇するとカーネル空間の確保不能。 | 5,000 未満で警戒 |
3.2 Paging File オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Usage | ページファイル(仮想メモリ)の使用率。ページファイルがどの程度使われているかを示す。 | 継続的に 70% 超でサイズ見直し |
| % Usage Peak | ページファイル使用率のピーク値。過去最大値の確認に使用。 | 90% 超はページファイル サイズ不足の可能性 |
切り分けのポイント
- Available MBytes が少なく Pages/sec も高い → 物理メモリ不足。増設を検討
- Pool Paged / Nonpaged Bytes が時間とともに単調増加 → カーネルレベルのメモリリーク。ドライバを疑う
- Committed Bytes が Commit Limit に近い → ページファイルサイズの拡張または物理メモリ増設
- 特定プロセスの Private Bytes(Process オブジェクト)が増加 → アプリケーションのメモリリーク
4. ディスク関連 Disk
物理ディスク・論理ディスクの I/O 性能、キュー長、応答時間を確認する。ディスクは現代のサーバで最もボトルネックになりやすいサブシステムである。
PhysicalDisk は物理ディスク単位、LogicalDisk はドライブレター単位の指標。カウンタ名はほぼ共通で、観察単位が異なる。
4.1 LogicalDisk / PhysicalDisk オブジェクト(共通カウンタ)
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Disk Time | ディスクが I/O 処理を行っていた時間の割合。ただし RAID や SSD では誤解を招く場合があり、Avg. Disk Queue Length と併用が望ましい。 | 80% 超が継続で要調査 (参考指標として) |
| Avg. Disk Queue Length | 指定期間中の平均ディスクキュー長(未完了 I/O 要求の平均数)。ディスクへの負荷集中度を示す最重要指標。 | スピンドル数 × 2 を超える 状態が継続で I/O ボトルネック |
| Current Disk Queue Length | サンプリング時点でのキュー長。瞬間値。 | スピンドル数 × 2 超 |
| Avg. Disk sec/Read | 1 回の読み取り I/O にかかる平均時間(秒)。ディスクの読み取り応答性能。最も重要な応答時間指標。 | HDD: 20ms 超で警戒 SSD: 5ms 超で警戒 NVMe: 1ms 超で警戒 |
| Avg. Disk sec/Write | 1 回の書き込み I/O にかかる平均時間(秒)。書き込みの応答性能。 | HDD: 20ms 超で警戒 SSD: 5ms 超で警戒 NVMe: 1ms 超で警戒 |
| Avg. Disk sec/Transfer | 読み書きを合わせた平均 I/O 応答時間。 | 上記 Read/Write と同等 |
| Disk Reads/sec | 1 秒あたりの読み取り I/O 回数(読み取り IOPS)。読み取り負荷の定量化。 | ディスク仕様上の IOPS と比較 |
| Disk Writes/sec | 1 秒あたりの書き込み I/O 回数(書き込み IOPS)。 | ディスク仕様上の IOPS と比較 |
| Disk Transfers/sec | 総 IOPS(Reads + Writes)。ディスクが処理している I/O の総量。 | ディスク仕様上の IOPS と比較 |
| Disk Read Bytes/sec | 1 秒あたりの読み取りスループット(バイト/秒)。帯域負荷の指標。 | 接続帯域の 70% 超で警戒 |
| Disk Write Bytes/sec | 1 秒あたりの書き込みスループット。 | 接続帯域の 70% 超で警戒 |
| Disk Bytes/sec | 総スループット(Read + Write)。 | 接続帯域の 70% 超で警戒 |
| Avg. Disk Bytes/Transfer | 1 I/O あたりの平均サイズ(バイト)。ワークロード特性(ランダム小 I/O か、シーケンシャル大 I/O か)を示す。 | ベースラインと比較 |
| Split IO/sec | 断片化等により 1 要求が複数 I/O に分割された回数。高値はディスク断片化やアロケーションユニット不整合の兆候。 | 急増時はデフラグ・ アライメント確認 |
4.2 LogicalDisk 固有カウンタ
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Free Space | 論理ドライブの空き容量割合。容量逼迫の監視。 | 20% 未満で警戒 10% 未満で緊急対処 |
| Free Megabytes | 空き容量の絶対値(MB)。特に大容量ボリュームでは % よりこちらを重視。 | 運用要件による |
切り分けのポイント
- Avg. Disk sec/Read または sec/Write が高い → ディスク応答性能不足。SSD 化・RAID 構成見直し・階層化を検討
- Avg. Disk Queue Length が長く応答時間も悪化 → ディスクサブシステムが飽和状態
- IOPS は低いが応答時間が悪い → ディスク異常、ケーブル不良、RAID 再構築中の可能性
- スループットが頭打ち → 接続インターフェース(SAS/FC/iSCSI)の帯域ボトルネック
- PhysicalDisk では問題なく LogicalDisk で問題あり → ファイルシステム層(NTFS/ReFS)の問題
5. ネットワーク関連 Network
NIC のスループット、エラー、帯域使用率を確認する。仮想化環境や 10GbE 以上の環境では特に重要。
5.1 Network Interface オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Bytes Total/sec | 送受信合計のスループット(バイト/秒)。NIC 全体のトラフィック量。 | Current Bandwidth の 60〜70% 超で帯域見直し |
| Bytes Sent/sec | 送信スループット(バイト/秒)。 | 同上 |
| Bytes Received/sec | 受信スループット(バイト/秒)。 | 同上 |
| Current Bandwidth | NIC の現在のリンク帯域(bps)。1Gbps NIC なら 1,000,000,000 等。リンク速度が期待値と一致するか確認。 | 期待リンク速度と不一致なら ケーブル・ポート設定確認 |
| Packets/sec | 1 秒あたりのパケット送受信数。小サイズパケットが多い場合、CPU 割り込み負荷の指標にもなる。 | ベースラインとの比較 |
| Packets Received/sec | 1 秒あたりの受信パケット数。 | 同上 |
| Packets Sent/sec | 1 秒あたりの送信パケット数。 | 同上 |
| Output Queue Length | 送信キュー長。送信待ちパケット数。 | 継続的に 2 以上で ネットワーク飽和の可能性 |
| Packets Outbound Errors | 送信エラーのパケット数(累積)。 | 0 が望ましい 増加はハードウェア異常 |
| Packets Outbound Discarded | 送信側で破棄されたパケット数。バッファ不足、リソース不足等で発生。 | 0 が望ましい |
| Packets Received Errors | 受信エラーパケット数(累積)。CRC エラー、アライメントエラー等。 | 0 が望ましい 物理層異常を疑う |
| Packets Received Discarded | 受信側で破棄されたパケット数。バッファ不足等。 | 増加時は NIC バッファ拡張を検討 |
5.2 TCPv4 / TCPv6 オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Connections Established | 現在確立されている TCP 接続数。サーバの接続負荷。 | アプリケーション設計値と比較 |
| Connections Active | 能動的に開かれた接続数(累積)。クライアント側動作。 | 急増時は異常接続試行を疑う |
| Connections Passive | 受動的に受け付けた接続数(累積)。サーバ側動作。 | ベースラインとの比較 |
| Connection Failures | 接続失敗回数。ESTABLISHED 状態到達前に CLOSED または LISTEN へ戻った数。 | 急増は対向障害または ネットワーク異常 |
| Connections Reset | RST により切断された接続数。 | 急増時はアプリ例外・タイムアウト確認 |
| Segments Retransmitted/sec | 1 秒あたりの TCP 再送セグメント数。ネットワーク品質の悪化を示す。 | Segments/sec の 5% 超で ネットワーク品質問題 |
切り分けのポイント
- Bytes Total/sec が Current Bandwidth に近い → 帯域不足。NIC チーミング・10GbE 化を検討
- Output Queue Length が常に長い → 送信飽和。QoS 設計見直し
- Packets Received Errors の増加 → NIC・ケーブル・スイッチポートの物理層異常
- Segments Retransmitted/sec の増加 → 対向との経路品質劣化、MTU 不整合
- 小パケット大量時に CPU 割り込み負荷が高い → RSS(Receive Side Scaling)の有効化を検討
6. プロセス / スレッド関連 Process
個別のプロセス・スレッド単位でリソース使用状況を確認する。システム全体の指標で異常を検知した後、どのプロセスが原因かを特定する際に使用する。
6.1 Process オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Processor Time | 当該プロセスの CPU 使用率(全コア合計)。プロセス単位での CPU 消費。論理コア数 × 100% まで取りうる。 | 常時 80%(1 コア相当) 超過のプロセスを確認 |
| % User Time | 当該プロセスがユーザーモードで消費した CPU 時間の割合。 | アプリロジックの重さ |
| % Privileged Time | 当該プロセスがカーネルモードで消費した CPU 時間の割合。高いとシステムコール過多。 | User Time とのバランス確認 |
| Working Set | プロセスが実際に使用している物理メモリ量(バイト)。ただし共有ページを含む場合あり。 | 物理メモリ量との比較 |
| Working Set – Private | プロセス固有の(共有されない)物理メモリ使用量。真のメモリフットプリントに近い。 | 継続増加はメモリリーク |
| Private Bytes | プロセスが確保した、他プロセスと共有しない仮想メモリ量。メモリリーク検知の最重要指標。 | 時系列で単調増加するなら リークの可能性大 |
| Virtual Bytes | プロセスの仮想アドレス空間使用量。ファイルマッピング等を含む。 | 32bit プロセスでは 2GB 上限 |
| Handle Count | プロセスが保持しているオブジェクトハンドル数(ファイル、レジストリ、カーネルオブジェクト等)。 | 継続増加はハンドルリーク 10,000 超は要調査 |
| Thread Count | プロセス内のスレッド数。異常増加はスレッドリーク。 | 継続増加はリークの可能性 |
| IO Read Bytes/sec | プロセスのファイル・ネットワーク・デバイス I/O 読み取り量(バイト/秒)。 | ベースライン比較 |
| IO Write Bytes/sec | プロセスの I/O 書き込み量(バイト/秒)。 | ベースライン比較 |
| IO Data Operations/sec | プロセスの I/O 操作回数。ファイル・ネットワーク操作頻度。 | ベースライン比較 |
7. IIS / Web サーバ関連 IIS
Windows Server で Web サービスを提供している場合の監視対象。IIS の役割サービスが有効な環境で利用可能。
7.1 Web Service オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Current Connections | 現在の HTTP 接続数。サイト単位・_Total で取得可能。 | サイト設計値と比較 |
| Connection Attempts/sec | 1 秒あたりの接続試行数。 | ベースライン比較 |
| Bytes Sent/sec | 送信バイト数(応答)。 | 帯域との比較 |
| Bytes Received/sec | 受信バイト数(要求)。 | アップロード負荷 |
| Get Requests/sec | 1 秒あたりの GET 要求数。 | ベースライン比較 |
| Post Requests/sec | 1 秒あたりの POST 要求数。 | ベースライン比較 |
| Not Found Errors/sec | 404 エラー応答数。リンク切れ・不正アクセスの兆候。 | 急増時は調査 |
7.2 ASP.NET / ASP.NET Applications オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Requests/Sec (ASP.NET Applications) | 1 秒あたりの ASP.NET 要求処理数。アプリケーションのスループット。 | ベースラインとの比較 |
| Requests Queued | ASP.NET が処理待ちとしてキューに入れている要求数。スレッドプール枯渇の兆候。 | 継続的に 0 より大なら スレッドプール調整 |
| Requests Rejected | キュー溢れ等により拒否された要求数(累積)。 | 0 が望ましい |
| Request Execution Time | 直近要求の実行時間(ミリ秒)。 | アプリケーション SLA と比較 |
| Request Wait Time | 直近要求のキュー待機時間(ミリ秒)。 | 急増はワーカー不足 |
| Errors Total/Sec | 1 秒あたりの ASP.NET エラー数。 | 0 が望ましい |
8. .NET CLR 関連 .NET
.NET アプリケーションを動作させているサーバで、GC(ガベージコレクション)、例外、メモリ使用状況を監視する。
8.1 .NET CLR Memory オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Time in GC | ガベージコレクションに費やされた時間の割合。高いと GC が処理を阻害している。 | 継続的に 10% 超で警戒 20% 超は即対処 |
| # Bytes in all Heaps | すべての世代ヒープの合計サイズ。マネージドメモリ使用量。 | 継続増加はリーク可能性 |
| # Gen 0/1/2 Collections | 各世代の GC 発生回数(累積)。Gen 2 GC は重く、頻発すると性能影響大。 | Gen 2 頻発はリーク疑い |
| Large Object Heap size | LOH(Large Object Heap)のサイズ。85KB 以上のオブジェクトが配置される領域。断片化しやすい。 | 継続増加は LOH 断片化・リーク |
8.2 .NET CLR Exceptions オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| # of Exceps Thrown/sec | 1 秒あたりの例外発生数。多いと性能劣化。 | 継続的に 100 超で アプリロジック見直し |
9. SQL Server 関連 SQL
SQL Server を稼働させているサーバで確認すべき主要カウンタ。インスタンス名により MSSQL$インスタンス名 オブジェクトとして表示される場合もある。
9.1 SQLServer:Buffer Manager オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Buffer cache hit ratio | バッファキャッシュからデータが取得できた割合。ディスク I/O 発生頻度の逆指標。 | OLTP: 95% 以上 90% 未満でメモリ不足疑い |
| Page life expectancy | ページがバッファプールに滞在する平均秒数。短いとメモリ圧迫。 | 300 秒未満でメモリ不足警戒 (メモリサイズに応じ変動) |
| Page reads/sec | 1 秒あたりの物理ディスクからのページ読み込み数。 | 急増時はクエリ/インデックス見直し |
| Page writes/sec | 1 秒あたりの物理ディスクへのページ書き込み数。 | ベースライン比較 |
| Checkpoint pages/sec | チェックポイントにより書き込まれるページ数。 | 急増はデータ変更量増 |
| Lazy writes/sec | 遅延書き込み回数。チェックポイント外での書き込み。メモリ圧迫の兆候。 | 継続的に 20 超で メモリ不足疑い |
9.2 SQLServer:General Statistics オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| User Connections | 現在の SQL Server ユーザー接続数。 | アプリ設計値と比較 |
| Processes blocked | 他プロセスにブロックされている SPID 数。ロック競合の指標。 | 継続的に 0 より大は要調査 |
| Logins/sec | 1 秒あたりのログイン回数。コネクションプーリング動作確認。 | 急増は接続プール設定不備 |
| Logouts/sec | 1 秒あたりのログアウト回数。 | ベースライン比較 |
9.3 SQLServer:SQL Statistics オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Batch Requests/sec | 1 秒あたりのバッチ要求数。SQL Server の総スループット指標。 | 環境のキャパシティと比較 |
| SQL Compilations/sec | 1 秒あたりのクエリコンパイル回数。 | Batch Requests の 10% 超は プラン再利用性に問題 |
| SQL Re-Compilations/sec | 1 秒あたりのクエリ再コンパイル回数。統計更新や一時テーブルで発生。 | 急増時はクエリ設計見直し |
9.4 SQLServer:Locks オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Lock Waits/sec | 1 秒あたりのロック待機発生数。 | 急増は競合激化 |
| Average Wait Time (ms) | ロック待機の平均時間。 | 500ms 超で要調査 |
| Number of Deadlocks/sec | 1 秒あたりのデッドロック発生数。 | 0 が望ましい |
10. Hyper-V 関連 Hyper-V
Hyper-V 役割を有効にしたホストで確認する仮想化固有のカウンタ。ホスト側の CPU カウンタ(Processor)ではなく、Hyper-V Hypervisor カウンタを見る必要がある点に注意。
10.1 Hyper-V Hypervisor Logical Processor オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Total Run Time | 物理コアが実際に使われていた時間の割合。ホスト全体の真の CPU 使用率。通常の Processor カウンタよりこちらを信頼する。 | 80% 超で VM 配置見直し |
| % Guest Run Time | ゲスト VM コードの実行時間の割合。 | ワークロード密度の指標 |
| % Hypervisor Run Time | ハイパーバイザー自身の処理時間の割合。高いと VM 数過多またはオーバーヘッド大。 | 5% 超は要調査 |
10.2 Hyper-V Hypervisor Virtual Processor オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| % Guest Run Time (vCPU 単位) | 個別 vCPU のゲスト実行時間割合。VM 単位の CPU 負荷把握。 | 80% 超で VM CPU 増設検討 |
| CPU Wait Time Per Dispatch | vCPU がディスパッチされるまでの待機時間。物理コア競合の指標。 | 継続的に高値なら ホスト CPU 不足 |
10.3 Hyper-V Dynamic Memory VM オブジェクト
| カウンタ名 | 意味・意図 | 目安・閾値 |
|---|---|---|
| Current Pressure | VM のメモリ圧迫度(%)。100 は VM 要求とホスト割当が一致、超えると不足。 | 継続的に 80 超で 動的メモリ上限見直し |
| Guest Visible Physical Memory | VM から見える物理メモリ量(MB)。 | 設計値と比較 |
| Physical Memory | VM に実際に割り当てられている物理メモリ量。 | Guest Visible と乖離 していないか確認 |
11. 代表的な監視シナリオ
11.1 恒常的な性能監視(日常運用)
ベースライン取得と傾向監視を目的とする、最小限のカウンタセット。
Processor(_Total)\% Processor TimeSystem\Processor Queue LengthMemory\Available MBytesMemory\Pages/secMemory\% Committed Bytes In UseLogicalDisk(_Total)\% Free SpaceLogicalDisk(_Total)\Avg. Disk sec/ReadLogicalDisk(_Total)\Avg. Disk sec/WriteNetwork Interface(*)\Bytes Total/sec
11.2 メモリリーク調査
Memory\Available MBytes(全体の空きメモリ)Memory\Pool Paged Bytes(カーネルリーク)Memory\Pool Nonpaged Bytes(カーネルリーク)Process(*)\Private Bytes(アプリケーションリーク)Process(*)\Handle Count(ハンドルリーク)Process(*)\Thread Count(スレッドリーク)
長期間(数時間〜数日)のトレンドを取得し、単調増加するプロセス・プールを特定する。
11.3 ディスクボトルネック調査
PhysicalDisk(*)\Avg. Disk sec/ReadPhysicalDisk(*)\Avg. Disk sec/WritePhysicalDisk(*)\Avg. Disk Queue LengthPhysicalDisk(*)\Disk Reads/secPhysicalDisk(*)\Disk Writes/secPhysicalDisk(*)\Disk Bytes/secProcess(*)\IO Read Bytes/sec(原因プロセス特定)Process(*)\IO Write Bytes/sec(原因プロセス特定)
11.4 仮想化ホスト監視(Hyper-V)
Hyper-V Hypervisor Logical Processor(_Total)\% Total Run TimeHyper-V Hypervisor Logical Processor(_Total)\% Hypervisor Run TimeHyper-V Hypervisor Virtual Processor(*)\CPU Wait Time Per DispatchHyper-V Dynamic Memory VM(*)\Current PressureMemory\Available MBytes(ホスト側)PhysicalDisk(*)\Avg. Disk sec/Read, sec/Write(VHDX 配置先)
11.5 Web / アプリケーションサーバ監視
Web Service(_Total)\Current ConnectionsWeb Service(_Total)\Bytes Total/secASP.NET\Requests QueuedASP.NET Applications(*)\Requests/SecASP.NET Applications(*)\Request Execution Time.NET CLR Memory(*)\% Time in GC.NET CLR Exceptions(*)\# of Exceps Thrown/sec
12. 運用上の注意事項
12.1 サンプリング間隔の選定
サンプリング間隔は目的によって使い分ける。
- 長期トレンド監視: 1〜5 分間隔。数日〜数週間のデータ保存が可能
- 日常監視: 15〜60 秒間隔。通常の性能監視に適切
- 障害調査: 1〜5 秒間隔。短時間の詳細取得に使用。ただしログサイズ急増に注意
- ベンチマーク: 1 秒間隔以下。短時間の測定のみ
12.2 しきい値判定の原則
- 一般的なしきい値はあくまで目安。実機のベースラインが最優先
- 瞬間値ではなく、一定時間(5〜15 分)の平均または継続時間で判定
- 単一のカウンタだけでなく、複数カウンタの相関で判断する
- ワークロード特性(OLTP、DWH、バッチ、Web)ごとに妥当値は異なる
12.3 データコレクターセット
パフォーマンスモニターの「データコレクターセット」機能により、複数カウンタをセットで記録・スケジュール実行できる。定期採取には必須。
- BLG 形式(バイナリログ)で保存すると、後でパフォーマンスモニターで再生可能
- CSV / TSV 形式で保存すると、Excel や他ツールでの分析が容易
- 円環ログとサイズ上限の設定でディスク枯渇を防止
12.4 パフォーマンスモニター自身の負荷
- サンプリング間隔を短くしすぎると、監視自体が CPU・ディスクに負荷をかける
- 多数のインスタンス(
Process(*)等)を採取するとデータ量が爆発的に増える - 本番環境では事前に検証環境で負荷影響を確認することが望ましい
12.5 カウンタ取得のコマンドラインツール
GUI 以外に以下のコマンドで操作可能。
typeperf: リアルタイムでカウンタ値をコンソール出力 / CSV 出力logman: データコレクターセットの作成・開始・停止・設定変更relog: BLG ファイルの形式変換・抽出・再サンプリング- PowerShell:
Get-Counterコマンドレットで取得・スクリプト化が容易