みなさま、こんにちは。Windows プラットフォーム サポートの横瀬です。
最近、パフォーマンス モニター (Perfmon) での CPU 使用率に関するカウンターのお問い合わせで、
類似した内容をお受けするケースがありましたため、以下 2 つのトピックについて、ご紹介いたします。
こちらの情報がご利用者様のお役に立てれば幸いです。
- 長い期間、再起動を行っていないシステムで CPU 使用率が不正な値を示す場合がある。
- パフォーマンス カウンターの Processor と、Processor Information について
① CPU 使用率が不正な値を示す場合がある。
CPU 使用率を確認するパフォーマンス カウンターには、
- Processor Time (システム全体の CPU 使用率)
- Privileged Time (カーネルの CPU 使用率)
- User Time (アプリケーションの CPU 使用率)
- Interupt Time (ハードウェア割り込みでの CPU 使用率)
- DPC Time (ドライバーが割り込みをハンドリングした際の CPU 使用率)
など、どのような用途で CPU が利用されたかを確認できるカウンターと
- Idle Time
など、アイドルだった割合を確認するカウンターが用意されています。
これらの値は、定期的にインクリメントされている情報を元に計算されており、それらの情報は、
各 CPU の管理情報の中に含まれております。またインクリメントされるデータは、32 bit のデータ長で
あることが殆どで、長い期間、運用している環境では値がオーバーフローしてしまい、前述いたしました
使用率が、不正な値を示す場合があります。
不正な値を示すケースとしては、以下の 2 パターンです。
パターンA : 突発的に 100% を超えた大きな数値が表示される。
パターンB : 数値が表示されない。
上記のどちらが発生するかは、オーバーフローしたデータと、それを使って、どのように値を
計算しているカウンターなのかに依存しますが、過去の報告事例としては、以下 2 つがあります。
▼ パターン A が出力されるケース
Privileged Time は、幾つかのデータを元に計算しており、1 つの要素として、サンプリング 間隔あたりに、
どの程度 Idle Time が変化したのか、その数値が含まれております。Idle Time が前述の オーバー フローの
影響を受けて 0xFFFFFFFF に近い数値から 0x0 へと変化した場合、Privileged Time を計算する仕組み上、
非常に大きな値を 元に計算されるため、100% を大きく超えた数値が出力される場合があります。
(過去事例では 6714569963 が表示されたようです)
▼ パターン B が出力されるケース
Idle Time は、複数のデータを元に計算しておらず、１つのデータ構造の差分を元に計算しております。
さきほどと同様に Idle Time がオーバーフローの影響を受けて 0xFFFFFFFF に近い 数値から 0x0 まで変化した
場合、Idle Time の計算上、マイナスの値になります。値がマイナスとなった場合、パフォーマンス モニターは
不正な値と判断して、数値を記録しません。
上記のように、不正な値が表示される事象がみられるのは、オーバーフローが発生した瞬間のみで、その後
0x0 にリセットされてからは、正常な値が記録されます。またオーバーフローするデータ 構造は CPU 使用率
などの統計情報を確認するデータで発生するため、ご利用いただいているアプリケーションや、サービスの
動作に対して、直接的な影響はありませんので、ご安心ください。
オーバーフローによる影響であるかは、システムの稼働時間を元に判定することができます。
パフォーマンス モニター ログを採取している場合、以下のカウンターをあわせて取得しましょう。
systemSystem Up Time
このカウンターはシステムが起動してからの経過時間を記録したもので、単位は秒となります。
弊社での確認結果、お問い合わせ事例等を見ますと、約 776 日を超えたところで、事象が発生しやすい
状況となっています。(経過時間が 776 * 24 * 60 * 60 = 67,046,400 秒あたり)
お客様環境において、CPU 使用率が不正な値を示した時間帯があった場合、前述のカウンターを参照し、
776 日に近い稼働日数になっていないか、確認してください。
事前に、この事象を回避する場合には、連続稼働日数が 776 日になる前に、計画的に再起動を実施する必要があります。
② Processor と、Processor Information について
CPU に関するカウンターで Windows Server 2008R2 以降、以下の 2 つのカウンターが用意されています。
Processor(*)
Processor Information(*)
お客様環境のハードウェア構成や、利用しているアプリケーションによっては Processor カウンターだけでは
調査ができないケースがあります。以下のパターンに該当する場合は Processor Information カウンターも同時に
採取することをお薦めします。
パターンA: NUMA Node グループを構成している環境での調査
パターンB: 省電力機能を有効化している環境での調査
パターンC: CPU 使用率の上下が非常に細かいアプリケーションの調査
▼ パターンA: NUMA Node グループ
NUMA 構成をサポートしているサーバーで、NUMA Node グループを分けている場合、Processor カウンターは、
NUMA Node#0 のみの数値を表示するため、サーバー全体の CPU 使用率を確認することができません。NUMA
Node グループを有効化している、或いは有効化する可能性がある環境では、Processor Information カウンターも
同時に採取することで、システム全体の CPU 使用率を確認できます。
▼ パターンB: 省電力機能を有効化している環境
ハードウェア側で省電力機能を有効化している場合、状況に応じて CPU Core が Parking 状態に入るケースがあります。
弊社過去事例にて CPU 使用率が低い状態にも関わらず CPU 待ちの処理数が増大したとの報告がありましたが、この
要因となったのが、この Core Parking 機能による影響でした。(省電力機能により Core が Parking 状態となり、処理
できる CPU が 一時的に減少していた)
Processor カウンターでは CPU Core ごとの詳細を確認することができないため、Active 状態で あるか Parking 状態であるか
確認することができません。電力消費を考慮して、省電力機能 を有効化している環境においては Processor Information カウンター
も同時に採取するようにします。
なお Core Parking の状態を確認する場合は、以下のカウンターを参照します。
Processor Information(*)Parking Status
▼ パターンC: CPU 使用率の上下が非常に細かいアプリケーション
Processor カウンターにおける CPU 使用率の計算は Idle Time を元に行われており、数値の算出は、おおよそ 10 msec の
インターバルで実施されています。そのため、非常に高速なCPU で且つ、非常に短い時間で処理を行うアプリケーション
を実行した場合、Idle と判定されてしまい、実際の CPU 使用率よりも、低く使用率が出てしまうケースがあります。
上記のようなケースにおいては、以下のカウンターを参照する必要があります。
Processor Information(*)% Processor Utility
このカウンターは Processor カウンターとは異なる方法で CPU 使用率を計算しており、前述のような処理時間が非常に
短いアプリケーションにおいても、実際の値に近い CPU 使用率が算出されます。
このカウンターは Windows Server 2012 以降で利用可能なカウンターです。
