こんにちは。 Windows テクノロジー サポートの田辺です。

リソース不足について - 第 2 回 では、ページ プールと非ページ プールについて もう少し掘り下げて見ていきたいと思います。

第 1 回と比較をすると細かい内容となりますが、トラブルシュートを行う上では欠かせない要素もいくつかありますので、がんばって進めていくことにしましょう。

割り当てられる領域につける名札について

ページ プールおよび非ページ プール内の領域が、各要求元のドライバに割り当て (Allocate) られる際には、Tag と呼ばれる 1 ～ 4 文字の名札がつけられます。

大抵この Tag には 要求元のドライバにより一意の文字が指定されるので、ドライバのどのような動作の際に確保されたプール (ページ プールもしくは 非ページ プール) なのかを判断する事ができ、この Tag 毎に使用されている値を見る事でプールの枯渇が発生した場合に、どのドライバが “限りあるリソース” を消費しているのかを追跡する事が可能となるのです。ただし、Tag そのものから確保されたプールがページ プールもしくは非ページ プールなのかを判別する事はできません。多くの場合、ページ プールと非ページ プールで共通の Tag が使用されます。

いくつか例を挙げてみますと、、、

MmSt - nt!mm        - Mm section object prototype ptes

Ntf? - ntfs.sys     - NTFS Specific allocation tags

Cc   - nt!cc        - Cache Manager allocations (catch-all)

といったものがあります。

これは OS が標準で使用しているものになりますが、各メーカーが開発しているドライバの中には、独自で指定している名前がいくつかあります。

余談ですがプールを確保する時は以下のようなパラメータを指定して Call されます。

PVOID   ExAllocatePoolWithTag(

IN POOL_TYPE  PoolType,

IN SIZE_T  NumberOfBytes,

IN ULONG  Tag                <<<<<

);

Tag がこの名札にあたるわけですね。ULONG つまり 32-bit 値なので、慣例上 8-bit の ASCII コード 4 文字が使用されます。

また、PoolType でページ プールもしくは非ページ プールの種類を、NumberOfBytes で確保するページの大きさを指定します。

詳しくは以下の Windows Driver Kit の Reference (英語) をご参照ください。

// ExAllocatePoolWithTag

http://msdn.microsoft.com/en-us/library/ms796989.aspx

Tag ごとのプール使用量を確認する方法について

では、さっそく Tag ごとのプール使用量を確認する方法について見ていきましょう。

Debugger を使用して確認を行う方法等もありますが、今回は Poolmon というツールを利用する方法について紹介させていただきたいと思います。

Poolmon は、システムのページ プールと非ページ プールをプール割り当て Tag ごとにグループ化して表示させる事が可能な トラブルシュートには欠かせないツールです。

尚 Windows Server 2003 以降ではプールの Tag 付けは既定で有効になっているため、有効にする必要はありませんが、Windows Server 2003 よりも以前の OS では、プールの Tag 付けを有効にしてコンピュータを再起動する必要があります。

Windows Server 2003 よりも以前の OS で、プールの Tag 付けを有効にするには、gflags.exe を使用するか、レジストリを直接編集してグローバル フラグを設定する必要があります。

Poolmon の利用方法と併せて、プールの Tag 付けを有効にする方法については、技術情報 177415 でも紹介しておりますので、是非ご一読ください。

さて Windows Server 2003 の場合、poolmon は Windows Server 2003 の CD-ROM の \Support\Tools フォルダの中で人知れず眠っています。この保存場所は Windows 2000 と Windows XP の場合でも変わりません。

ここにある Support.CAB を展開すると、Poolmon.exe がいますので、目を覚ましてもらう事にしましょう。

(こう書くとちょっと怪しい技術書風になりますね)。

使用方法は至って簡単です。コマンド プロンプトの画面で、Support.CAB ファイルを展開したフォルダまで cd コマンドで移動して poolmon.exe と実行するだけです。

ちなみにコマンド プロンプトの画面は既定では小さなウインドウのため、[簡易編集モード] や [挿入モード] の有効化と、レイアウトの横と縦のバッファは十分な値を設定する事をお勧めします。この辺は好みに合わせてプロパティから変更してください。

私は コマンド プロンプトを使用する機会が多く、前に入力したコマンドが見えなくなってしまうのが困るので、縦が 9999、横が 200 くらいのバッファを指定していつも使ってます。こうすると全画面表示にも対応できる位のサイズになり、おかしな改行が入らないので非常に重宝します。

では さっそく Poolmon.exe を実行して、、、といきたいところですが、その前に第 1 回目の内容の復習も兼ねて実際に発生している問題のトラブルシュートを一緒に行っていきたいと思います。

まずは用意をしたテスト環境で前回ご紹介いたしました Memory\Pool NonPaged Bytes もしくは Memory\Pool Paged Bytes を見ていきます。

するとこの環境では、以下のように Pool Nonpaged Bytes が右肩上がりに上昇している事がわかりました。これだけで判断するには短期間過ぎではありますが、非ページプールが右肩上がりに上昇していて、リークが発生しているように見受けられます。

非ページ プールがリークしている可能性がある事がわかりましたので、ここからは実際に poolmon を使用して 非ページ プールを使用しているドライバを特定していきます。

コマンド プロンプト上で poolmon.exe と入力して実行すると、コマンド プロンプト上で以下のような画面が表示されたと思います。

この状態で 2 番目の列 "type" に "Nonp" という値が表示されるまで P キーを押します。

そして B キーを押すと、列の値が降順 (最大バイト利用数の順) で並べ替えられます。

簡易編集モードが有効の場合には、画面全体を選択してから右クリックをする事でコピーする事が出来ますので、そのまま notepad 等のテキスト エディタに張り付けます。この繰り返しで、そのタイミングの Tag 毎のプールの利用状況を残す事が出来ます。Poolmon.exe には、B の他にも出力を並べ替えるキーが 技術情報 177415 で紹介されてますので、目的に合わせてソートするようにしてください。

スナップショットはありませんが上の MeHE という Tag の使用量 (Bytes) が時間を追うごとに増えていることがわかります。ソートをしなおしても同じように増加をしていく Tag が無いため、全体量である Pool NonPaged Bytes を増加させていたのは、MeHE Tag である事がわかりました。

では 続いてこのドライバが何なのかを確認する事にしましょう。

Driver を特定する方法について

サードパーティ製のドライバによって使用されているプール Tag からドライバを特定する場合には、標準のコマンド “findstr” が大活躍します。

このコマンドを利用して各ドライバのバイナリ データから文字列を検索し、Tag 名と同じ文字列が含まれているドライバをある程度洗い出す事が出来るんですね。

サードパーティ製のドライバによって使用されているプール Tag の検索方法については、技術情報 298102 でも紹介しておりますので併せてご参照ください。

今回は MeHE という Tag で割り当てられた非ページ プールが時間を追う毎に増加しているような状況でしたので、MeHE という Tag を使っているドライバを特定したいと思います。

では早速実行してみましょう。

以下のコマンドを %systemroot%\system32\drivers 内のドライバに対して実行します。

> C:\Windows\System32\drivers>findstr /m /l MeHE *.sys

/m でファイルに一致する行があるときに、ファイル名のみを出力し、/l で検索文字列をリテラルとして使用、そして *.sys でドライバを指定しているといった塩梅です。検索を実行すると、実行後以下の結果が返されてきました。

> C:\Windows\System32\drivers>findstr /m /l MeHE *.sys

> Sheep.SYS

この結果からは、Sheep.SYS に MeHE という文字列が含まれている事がわかりましたので、Sheep.SYS が非ページ プールを割り当てる際に、MeHE という Tag を使用している可能性がある事がわかりました。

今回は意図的にリークが発生するように実装したドライバ (Sheep.sys) を使用してテストを行いましたので、結果としてドライバの特定まで出来て大成功という事になります。

// 補足

コマンドからだけでは無く、Tag を使用してエクスプローラからの検索も行う事が出来ますので是非お試しください。

ちなみにファイルの場所は drivers 配下だけではなく、%SystemRoot%、%ProgramFiles%、%SystemDrive%、%ProgramData% などのより広い範囲を対象として実行するなど、より包括的な検索を行わなければドライバを特定できない可能性があります。

drivers 配下に無い場合には、色々なフォルダ内を確認いただければと思います。

Driver が特定出来たらどうするか

Driver が特定出来たらどうするか ですが、自分で Driver を書いている方であればそのまま修正のコードを入れる事も出来ますが、簡単に修正を入れる事が出来ない方のほうが大多数かと思います。その場合には、もしリークが発生していた場合には、回避策としては再起動しかありません。

後はドライバの提供元にご相談をしていただき、解放漏れがある処理が無いかを確認してもらい、その部分が修正したモジュールを提供いただく他には無いので、リソース不足からドライバの特定ができた場合には、まずは提供元のメーカーにご相談いただくのが一番確実な対応策になります。

切り分け方法としては findstr 等で特定していただいたドライバを一時的に無効にして現象に変化が無いかを確認したり、更新された最新のドライバがあれば最新版のモジュールをインストールして確認を行ったりといろいろとありますが、まずは最新版のモジュールに更新していただくのが良いかと思います。

既に修正されている可能性があり、一番効率的なトラブルシュートなため、存在するかもわからない場合には提供元のメーカーにご相談ください。

注意事項

ちなみに一番多く使用しているから悪いのか？と言われるとそうでも無いのが困ったところでもあります。

うっかりだまされてしまうと、なかなか問題の解決に至らずに取り返しのつかない事にもなりかねません。

実はどのドライバがリークを引き起こしているのか、もしくは問題があるのかというのは、私たちも判断が非常に難しい時があります。

椅子取りゲームよろしく 共有されているリソースを取り合っているだけなので、実は確保している事に問題が無いとか、そのタイミングでは絶対に必��なので、むしろ他の部分でトリミングを行わなければいけないといったような事があるために、ただ一番多く消費しているからといって、問題ではない場合もありますのでご注意ください。

最後に

第 2 回まででページ プールと非ページ プールについてざっくりとではありますが、確保しているドライバの特定方法も含めて踏み込んだ解説をさせていただきました。

ボリュームが大きく わかりづらい内容ではありますが、詳細なトラブルシュートをする上では理解しておく必要がある部分ではありますので、実際に問題があった時などにここで紹介させていただいた事を思い出していただければと思います。

次回の第 3 回では、第 1 回で少し触れました ページ プールと非ページ プールの最大値を確認する方法についてと、Windows Vista と Windows Server 2008 でのページ プールと非ページ プールについてを紹介させていただこうかと思います。

Windows Vista 以降ではいろいろと変更があり、寂しい限り？ですがリソースの枯渇という事もあまり聞かなくなりました。そんな Windows Vista 以降の OS で、ページ プールと非ページ プールについてを中心に第 3 回は紹介させていただきますのでどうぞご期待ください。

~ 第 3 回 へつづく ~ 

- リソース不足について - 第 1 回

こんにちは。 

Windows テクノロジー サポートの新川です。

今回は、システム イベントで以下のように、「VolSnap 33 が大量に記録され、最終的に VolSnap 24 や 35 も発生し、VSS の以前のバージョンが全て消えてしまった」という問題について、Windows Server 2003 での VSS の動作を含めて説明します。

**************************************************

イベントの種類: 情報

イベント ソース: VolSnap

イベント カテゴリ: なし

イベント ID: 33

説明:

ボリューム X: の最も古いシャドウコピーは、ボリューム X: のシャドウ コピーの使用ディスク領域をユーザーが定義した制限より小さく保つために削除されました。

**************************************************

 ・

 ・

**************************************************

イベントの種類: 警告

イベント ソース: VolSnap

イベント カテゴリ: なし

イベント ID: 24

説明:

X: のシャドウ コピーのシャドウ コピーの記憶域を拡大するためのディスク領域がボリューム X:に十分ありませんでした。

このエラーの結果、ボリューム X:  のシャド���コピーすべてが削除される危険があります。

**************************************************

イベントの種類: エラー

イベント ソース: VolSnap

イベント カテゴリ: なし

イベント ID: 35

説明:

シャドウ コピーの記憶域を拡張できなかったためにボリューム X: のシャドウ コピーが中止しました。

**************************************************

何が問題か？

VSS において、各ボリュームの以前のバージョンは 64 世代が最大です。

65 世代目のスナップショットを作成したり、差分データを拡張する時などに、HDD の容量が足りなかったり、VSS の記憶域として設定した容量を超えてしまいそうな場合に、VolSnap 33 が出て必要な分だけ削除されてしまう事自体は正常な動作であり、これは仕方がありません。

しかしながら、ご利用いただいている方からすると非常に困るのは、「ディスクにまだ空きはあるのに、大量に VolSnap 33 が出てしまって、ほとんど全ての世代の差分データが消えてしまった」という場合ではないでしょうか？

その場合、上記のような VolSnap 33、24、35 や、処理状況によって、VolSnap 39 が合わせて記録されているはずです。

これは、Windows Server 2003 上で VSS の保護対象と記憶域が同一ボリュームである環境で発生しうる問題です。

これには VSS の動作が関係しており、根本的な回避を行うには保護対象と記憶域を別ボリュームにしていただく必要があります。

その内容について、VSS を理解する上でいくつか重要なキーワードと併せて説明します。

---------------- 

DiffArea と差分データ

はじめに、VSS の基本動作についてです。

VSS ではスナップショットを作成し、元々データが存在していたブロックが更新される際、「DiffArea」という領域に退避させておきます。

以前のバージョンとして参照する際は、DiffArea の中にあるブロックから古いデータを取り出す事で可能にします。

DiffArea は Windows Server 2003 SP1 以降の環境では、既定で 300MB の領域です。

予め 300MB 確保しておいて、変更量が多くて退避されたデータが 300MB に達しかけた時点で、DiffArea を拡張する事になります。

また、更にもう 1 世代追加でスナップショットが実行された場合、DiffArea 内に退避されたデータはその世代の「差分データ」として切り離します。

そして、改めて DiffArea が作成しなおされ、それ以降の変更情報がまた DiffArea に保存されていく事になります。

したがって、以前のバージョンの機能を使って数世代前のデータを取り出すには、「DiffArea 内の差分データ」~「自分の世代までの差分データ」で、遡りながら必要なブロックを参照する事で可能となります。

ビットマップと Copy-On-Write

時々、「VSS ではスナップショットを撮った後の変更データを保存しているんでしょ？」という風に理解をされている方がいらっしゃいますが、そうではありません。

VSS ドライバは、スナップショットが実行された時点で、保護対象のボリュームを 16KB 単位で分割し、元々データが存在していたか、変更が発生したか否かを「ビットマップ」で監視しています。

ビットマップ上で、データが存在していると認識されているブロックに対して変更を行う場合に、変更前のデータを DiffArea に退避します。

つまり、Write 処理が発生した時に初めてコピーされる事になりますので、VSS では「Copy-On-Write」処理を用いているという事になります。

万が一、拡張処理に失敗するなどで DiffArea 内に十分な領域がないと VSS は Copy-On-Write 処理が行えず、差分情報をトレースする事ができなくなってしまうため、VSS はリセットされる事になります。

リセットされた場合は、以前のバージョンは全て削除される事になります。

何故 VolSnap 33 は記録されるのか？

繰り返しになりますが、VolSnap 33 は、DiffArea を新規作成、もしくは拡張する際に容量が足りない場合、空き領域を確保するために発生します。

 容量が足りないために一番古い世代の差分データを消す事で、ディスクの空き領域を確保しようとするわけですが、一番古い差分データを消しても十分な空き容量が確保できない場合、更にその時点で一番古い世代を消します。

この動きそのものは正常ですが、消しても消してもある理由から必要な領域が確保できないために、ほとんどの世代 (差分データ) が削除されてしまい、最終的に全部削除にまで至る場合があります。

領域とはディスク上の領域を指しますが、ディスク容量に十分に空き領域があるように見えても、足りない状況が発生する事があります。

空き領域とは？

DiffArea をディスク上に配置する際、以下を満たしている必要があります。

1. ボリューム上の空き容量が十分にある

2. 記憶域の最大値に対する空き容量が十分にある

3. VSS 上で利用可能と認識されているブロックが十分にある

1. は、ファイルシステムから見たボリューム上の空き領域です。2. も VSS の記憶域に上限値をつけた場合に適用される容量ですが、基本的にはファイルシステム上での容量です。

これらは、ボリュームのプロパティなどで見てもすぐに確認ができますが、目にも見えず問題となってくるのが、3. の「VSS 上で利用可能と認識されているブロック」です。

1. や 2. の領域は、差分データを削除する事で確保する事が可能ですが、3. の領域は保護対象と記憶域が同一ボリュームになっている場合、ほとんど増やす事ができません。

理由は、差分データも���護が必要な一つのファイルとして認識されているからです。

保護対象となっているファイルは、スナップショット実行後に削除された場合でも、ビットマップ上ではデータが存在していたブロックとして認識されているため、そのブロックに書き込みを行う際は、DiffArea への Copy-On-Write が必要となります。

全ての差分データが消えてしまう

上記は言い換えると、Copy-On-Write を行わないと空けたはずのブロックに書き込みができないわけですが、そもそも DiffArea が足りなくて拡張処理を行っているので、Copy-On-Write はできない状況です。

そうなると、VSS では空き領域を確保するために、更に一番古い世代の差分データを削除します。

しかし、差分データの中でもデータが配置されていたブロックは Copy-On-Write を行わない限り書き込み可能とならない状況は続いているため、一番古い世代の差分データを削除しても 3. のブロックは増えず、更に次々と再帰的に削除されてしまう事になります。

差分データの削除により、途中で運よく利用可能になったブロックが十分に見つかればよいのですが、DiffArea ではある程度まとまった連続領域も必要であるため、空き領域として認識されるには、非常にシビアな状態です。

大量に削除される事で VolSnap 24 が発生しますが、全部消えてしまっても空きブロックが見つからない場合、DiffAreaの拡張処理が失敗し、最終的に VSS が一旦リセットされてVolSnap 35 が記録される事になります。スナップショット実行時であれば、VolSnap 39 が記録されて失敗する事となります。(この場合、残っている DiffArea にまだ書き込み可能であれば、以前のバージョン全てが消えない事もあります)

対処するには？

Windows Server 2003 環境での対処方法としては、冒頭に申し上げた通り、保護対象ボリュームと VSS 記憶域のボリュームを別々にする事になります。

記憶域が保護対象ボリューム上にない事で、削除した差分データが存在していた領域がすぐに利用できる事となります。

なお、Windows Server 2008 ではこの点について大きなデザイン変更が実施されており、VolSnap 33 が発生した際にビットマップを再計算して 3. のブロックを新たに設定しなおす事で改善されています。

しかし、誠に残念ながら非常に大きな変更であるため、Windows Server 2003 適用する事ができていません。

暫定対処は？

もし、Windows Server 2003 の環境において、どうしても記憶域ボリュームを別にする事ができない場合には、VSS の世代数を制限することで、各ブロックが参照されている確率を抑える事ができるため、この問題に対してある程度の抑制はできると考えられます。

下記に記載しますレジストリで、VSS の世代数は制限可能ですので、ご検討ください。

- 手順例（5 世代までの保存とする場合）

1. [ スタート ] - [ ファイル名を指定して実行 ] をクリックして [ regedit ] と入力し、Enter キーを押します。

2. 次のレジストリ サブキーを見つけて右クリックします。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings

3. [ 新規 ] をポイントして [ DWORD 値 ] をクリックします。

4. MaxShadowCopies と、入力し Enter を押します。

5. MaxShadowCopies をダブルクリックし、 値のデータボックスに 5 を入力して [ OK ] をクリックします。

6. レジストリ エディタを終了します。

7. コンピュータを再起動します。

-参考資料

Article ID: 945058

When you use the Volume Shadow Copy Service on Windows Server 2003-based computers that run many I/O operations, disk volumes take longer to go online

http://support.microsoft.com/kb/945058/en-us

http://support.microsoft.com/kb/945058/ja（機械翻訳）

こんにちは。Windows テクノロジー サポートの石井です。

今回は、バックアップ製品である DPM 2007 Service Pack 1 インストール時に残る一時ファイルについてご説明します。

インストール処理終了後は削除可能

DPM 2007 SP1 と SP1 の保護エージェントのインストール後に、DPM サーバーや保護対象に多数の一時ファイルが残ります。

以下のファイルがそれにあたりますが、これらは削除いただいても差し支えありません。

これらのファイルは、SP1 適用や保護エージェントのアップデート時に、最も空き容量の多いボリュームに残ります。

eula.1028.txt

eula.1031.txt

eula.1033.txt

eula.1036.txt

eula.1040.txt

eula.1041.txt

eula.1042.txt

eula.2052.txt

eula.3082.txt

globdata.ini

install.exe

install.ini

install.res.1028.dll

install.res.1031.dll

install.res.1033.dll

install.res.1036.dll

install.res.1040.dll

install.res.1041.dll

install.res.1042.dll

install.res.2052.dll

install.res.3082.dll

VC_RED.cab

VC_RED.MSI

vcredist.bmp

そもそも何のファイルか

上記ファイルは、当該一時ファイルを残す動作は SP1 や SP1 の保護エージェントのインストール時に最初にインストールされる、

Vcredist.exe と呼ばれる Microsoft Visual C++ ランタイム ファイルなど、アプリケーションのアップデートに使用されるコンポーネントの一時ファイルです。

(この現象については、現在の最新のバージョンの Vcredist.exe では一時ファイルを残さないように変更されています。)

次回以降も、DPM 2007 についてよく寄せられるお問い合わせや、気になる動きの詳細などを

ご紹介していきたいと思いますので、ご期待下さい。

こんにちは。

Windows テクノロジー サポートの大羽です。

今回は SCVMM の設定について、一点補足説明をさせていただきます。

SCVMM 上でゲスト OS を作成する際のハードウェア プロファイルで、プロセッサ設定欄に以下のような「CPU の種類」という項目があります。

この「CPU の種類」の定義が分かりにくいため、お客様よりお問い合わせをいただくことがあります。

実際、ヘルプなどの説明では理解しづらいため、今回はそのあたりの説明をしたいと思います。

通常、ゲスト OS を作成するためのウイザード上で「CPU の種類」というキーワードが出てきますと、ゲスト OS の仮想プロセッサを想像するかと思います。

上のスナップショットにありますように「Pentium 4」「Xeon」という具体的な設定項目もあるため、一見ゲスト OS の仮想プロセッサを選択できるように見えます。

しかし、この設定箇所ではゲスト OS 自体にはなんら影響しません。

結論から申し上げますと、この「CPU の種類」ではゲスト OS を他のホストに移行する際の「ホスト評価」で利用される値という以外の意味を持ちません。

SCVMM では Hyper-V ホストなどの複数の仮想環境をホスト管理することが可能となっており、そのホスト間をシームレスにゲスト OS を移行できるというのが製品のセールス ポイントでもあります。

その移行の際に適切な移行先ホストを選択する手助けとなる "ホストの評価" という指標があります。

具体的には、ホストの移行を実施いただく際に、★印によって示される指標になりますが、CPU の使用率、空きメモリなどの評価から計算され、ゲスト OS を配置するのに適切なホストに対しては「★★★★☆」といった形で示されます。

※★が多いほど、適しているという評価になります。

How Virtual Machine Manager Rates Hosts

http://technet.microsoft.com/en-us/library/dd250807.aspx

以下の画面ですと、yasuhito1 というホストが移行先として一番適している「ホストの評価」となっています。

その際、ゲスト OS 毎に微調整を行いたい場合は、ゲスト OS 上の "CPU の種類" を設定いただくことで、スターレートが +0.5、-0.5 といったレベルで調整が可能です。

残念ながら具体的な計算式については公開されていないので、それぞれの環境で色々と試してみてください。

※ちなみにテストした限りでは、あまり大きな変化は見られなかったです。

   ですので、やはり微調整という位置付けですね。

具体的なシナリオとしては、まだ用意させていただいておりませんが、ゲスト OS を物理環境に配置した場合に、どの程度のハード スペックで動作するのか、といった観点で設定をいただければ、より適切なホストの評価が実現いただけると思われます。

あくまで補助的な役割ですし、最終的には手動選択となりますので、参考程度とお考えください。

- ご参考

SCVMM "Processor" setting