＜２．パフォーマンスDLLの作成＞
レジストリにモニタ対象のアプリケーションをモニタする情報を登録して、
コントロールパネル→管理ツール→パフォーマンスから表示されるパフォーマンスデータ収集アプリを
起動すると、パフォーマンスモニタシステムは、レジストリ情報に従ってパフォーマンスDLL
をロードして、その仕様に沿ったコールバック関数を呼ぶことによって目的のデータを収集しようとします。
このコールバック関数を実装することが今回のテーマの中心になります。
システムが呼び出す関数なのでそのシグネチャは決まっていて何を実装するかも指針が示されています。
そのコールバック関数は３つあり、次のような機能を実装します。
(２a．Open関数)
パフォーマンスデータ収集アプリがRegQueryValueExを呼び出すと パフォーマンスモニタシステムはレジストリ情報を元にDLLをロードします。ただし、別のアプリが RegQueryValueExを呼んでいたらDLLはロードされています。 DLLのロード後、 １つのスレッドが最初に一度だけ呼ばれる関数がOpen関数です。プロトタイプは
DWORD WINAPI OpenPerfData(LPWSTR lpDeviceNames);
です。
| 引数 | lpDeviceNames | レジストリのHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\application_name\Linkage のExportエントリに格納されている文字列が渡されています。 |
| 戻値 | 初期化等の必要処理が正常に行われた場合は、ERROR_SUCCESSを返却するようにします。 エラーなどが発生して、以降のパフォーマンスデータ収集ができない場合は ERROR_SUCCESS以外の値を返してイベントログに記録します。この場合、システムから 以降のCollect関数、Close関数は呼ばれません。 |
- まず関数名ですが、任意の名前でいいですが、作成した レジストリキーの"Open" エントリの値と一致している必要があります。
-
このDLL内の関数でカスタムパフォーマンスデータを返却しますが、
その内容はPERF_OBJECT_TYPE、PERF_COUNTER_DEFINITION、PERF_INSTANCE_DEFINITION
(インスタンスがある場合)、PERF_COUNTER_BLOCKを含むカウンタデータです。
このうち、データ収集タイミングによって変わらない値、 例えばPERF_OBJECT_TYPEのObjectNameTileIndexなどのインデックスや各構造体のバイト数、 PERF_COUNTER_DEFINITIONのCounterTypeなどの個々のカウンタの属性をOpen関数で初期化します。 インデックスは登録したレジストリキー のFirst Counterエントリの値に オフセット値を記録した C++のヘッダファイル(headerfile.h)の 値を加えて作成していきます。
PERF_INSTANCE_DEFINITION、PERF_COUNTER_BLOK以下のカウンタデータについては、カウンタデータ収集 タイミングによってそのインスタンス数から違ってくるので、この関数内では何もしません。 - イベントログの初期化。初期化ができない等のエラーが発生した場合この関数で処理を止めてはいけません。 RegQueryValueExの第二引数に"Global"を指定してデータが取得されようとしていたら、 パフォーマンスデータシステム全体に影響を及ぼします。エラー報告の唯一の方法である イベントログによって行い、ERROR_SUCCESS以外の戻値を返却するようにします。このイベントログの 初期化をこの関数内で行います。具体的にイベントログの初期化とは何かということは、 本題とかけ離れるのでまた別の機会があればそちらで書きたいと思います。
- モニタ対象アプリケーションとの通信手段の確立。Open関数のあと、パフォーマンスシステムから Collect関数が呼ばれてモニタ対象アプリケーションからデータを収集するよう要求されますが、 そのアプリケーションと通信をしなければデータを取得できません。当然、Open関数、 Collect関数のDLLのプロセスと、アプリのプロセスは異なるのでデータの収集は簡単ではないです。 この通信は一般にプロセス間通信と呼ばれていますが、その方法はいくつかあり、 かつなかなか難解です。以降の例では通信方法はそのうちのひとつである共有メモリを使った 方法で実装しますが、別テーマとして書いてある のでそちらで理解してください。
- 実行形式はDLLでインスタンスは１つなので、複数のパフォーマンスデータ収集アプリのスレッドから 呼ばれる可能性があるので、あるスレッドがデータ収集を終了してClose関数で後処理をしないように、 DLLにアクセスしているスレッド数の管理も行います。
- その他に必要な初期化処理があればここで行います。
（２b．Collect関数）
Open関数で初期化処理が正常に終了してERROR_SUCCESSが返されると、 システムは続いてCollect関数を呼び出します。プロトタイプは次のとおりです。
DWORD APIENTRY CollectPerfData(IN LPWSTR lpwszValue,
IN OUT LPVOID *lppData,
IN OUT LPDWORD lpcbTotalBytes,
IN OUT LPDWORD lpNumObjectTypes);
| 引数 | lpwszValue | RegQueryValueExの第二引数で指定される収集しようとしているパフォーマンスオブジェクトの リストが収められている文字列(ex. "Global", "Foreign xxx", "Costly", "344 132") |
| lppData | PERF_OBJECT_TYPEを先頭とした、収集したデータを含む返却すべきデータブロックの先頭位置への ポインタがシステムより提供されます．正常にデータ収集ができて、*lppDataにデータを返却できたら、 次のオブジェクトがパフォーマンスデータを返却できるように、データを格納した最終位置 (次のオブジェクトがデータを格納する最初の位置）に*lppDataの位置を移動しなければなりません。 | |
| lpcbTotalBytes | Collect関数でオブジェクト／カウンタの返却データに必要だと思われる総バイト数をシステムが 推定してここの引数に提供されます。*lppDataに正常にデータが書込みできたら、 格納したバイト単位のサイズを返却します。 | |
| lpNumObjectTypes | 正常にデータを取得して返却できた時、システムに返却したカウンタオブジェクトの 種類数を設定します。 | |
| 戻値 |
システムが推定して*lpcbTotalBytesに渡した返却用メモリ領域よりも、実際に返却するメモリ領域の
ほうが大きい場合、つまり、結果が収まらないときはERROR_MORE_DATAを返します。 それ以外、正常にデータ収集できた場合やそもそもこのカウンタオブジェクトに関連する カウンタデータを収集する必要が無い時、あるいはエラー時の場合などERROR_MORE_DATAを返す以外は すべてERROR_SUCCESSを返します。 |
- 関数名はOpen関数の場合と同様、作成した レジストリキーの"Collect" エントリの値と一致している必要があります。
- エラーの場合やこのカウンタオブジェクトに関連するデータを返却する必要がない場合は、 先ほど書いたように戻値で判断させないで、*lpcbTotalBytes、 *lpNumObjectTypesを0に設定して、*lppDataの位置は何も変更を加えないようにして関数を終了させます。 すると、システムはこのDLLに関するカウンタオブジェクトの値は呼び出し元に報告しません。
- この関数の主要目的は オブジェクト／カウンタの設計 でプランを立てたカウンタオブジェクト／カウンタ定義／カウンタデータをシステムに返却することです。 そのデータとは既に何度も出てきていますがPERF_OBJECT_TYPEを先頭とした以下のようなメモリブロックです。 (先頭がPERF_DATA_BLOCKではないので注意。）
 |
先頭がPERF_DATA_BLOCKでないのはこのDLLのCollect関数では、 あたなた作ったパフォーマンスデータだけをシステムは必要としていて、最終的に RegQueryValueExの第二引数に指定した範囲のカウンタデータを取得したシステムがデータを まとめてPERF_DATA_BLOCKを先頭にして呼び出し元に返却します。 データ収集の手順は次のようになります。
|
その際注意しなければならない点は、Collect関数内のローカル変数にデータをいったん 蓄えて*lppDataにコピーする場合です。前にも書きましたが、複数のスレッドがこのDLLに アクセスする可能性があるので、AスレッドがカウンタデータをCollect関数内のローカル変数xに 取得したとします。xを*lppDataにコピーするまでにスレッドBがCollect関数を呼び出して変数xを 初期化してしまったら、Aスレッドの収集データがおかしな値になります。こんなことを避けるために 収集データは直接*lppDataにコピーするのが吉かもしれません。
- モニタ対象のアプリケーションからデータを収集する際にはちゃんと同期をとるなどの処置が 必要ですが、今回のパフォーマンスモニタというテーマとは直接関係ないので プロセス間通信でデータ取得方法を確実に理解してください。
-
返却すべきデータをコピーしたら、そのトータルバイト数をPERF_OBJECT_TYPEの
TotalByteLengthメンバと、lpcbTotalBytes引数に設定してください。このとき、
このバイト数は8の倍数でなければなりません。パフォーマンスデータはLONGLONG型の
データが存在していてシステムは8バイトずつ読み取るようです。
winperf.hを見るとわかりますが、PERF_OBJECT_TYPE、PERF_COUNTER_DEFINITION、 PERF_INSTANCE_DEFINITiONのサイズは8の倍数なので、この構造体のメンバの値を操作している分には 何も気にする必要はないですが、インスタンス名を格納する領域や、PERF_COUNTER_BLOCKの 先頭から最後のカウンタデータまでのサイズが8の倍数になるように気をつける必要があります。 - Collect関数でカウンタのインスタンス数も算出されているので*lpNumObjectTypesに設定します。
- もし、何らかのエラーが発生してもERROR_SUCCESSで関数を終了して、エラー内容は唯一の 方法であるイベントログを使うようにします。
(2c. Close関数）
パフォーマンスデータ収集アプリが終了してRegCloseKeyを発行するとスレッドごとに 最後に一度だけClose関数が呼ばれます。プロトタイプは次のとおりです。
DWORD WINAPI ClosePerfData();
| 戻値 | すべてERROR_SUCCESS |
- 関数名はOpen関数、Collect関数の場合と同様、作成した レジストリキー の"Close"エントリの値と一致している必要があります。
- DLLにアクセスしているスレッドが１の場合、このClose関数呼び出しが最後になるので、 イベントログの終了処理やモニタ対象アプリとの通信切断などの終了処理を行います。
- Open関数で行っていたDLLにアクセスしたスレッド数のインクリメントに対して、 Close関数はスレッドで最後に呼ばれる関数なのでスレッド数のデクリメント処理を行います。
＜３．モニタリング対象アプリケーションからのデータ取得のための実装 −プロセス間通信＞
後で記述する例のモニタ対象アプリケーション側では、共有メモリを作成して そこにデータをコピーをします。パフォーマンスDLL側のCollect関数でこの共有メモリから データを取得する形でプロセス間通信を行っています。プロセス間通信にはいろいろな方法がありますが、 ここでは趣旨が違うのでこれ以上書きません。 例の共有メモリを使う方法については こちらで確認してください。
＜４．イベントログの実装＞
DLLの実装の際、エラー報告は先に書いたようにイベントログしかないので イベントビューア等で状況を把握できるようにイベントログを記録できるようにしなければなりませんが、 これも、３．のプロセス間通信と同様今回の趣旨と異なるので コードの掲載と簡単な説明に留めておきます。また、機会があれば書きたいと思います。
カスタムパフォーマンスモニタの実装でやるべきことの大筋は上記のような感じなので、 次から実践してみます。