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

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

システムの管理を行っていると必ずと言って良い程直面するのが、システムのリソース不足だと思います。

システム リソースって？と聞かれるとまず思いつくのが、物理メモリになるかと思いますが、システムで使用しているリソースは、実は物理的に搭載しているメモリだけではありません。

そこで今回はシステム リソースの中からも、デバイスの開発者やサポート業務等に従事している方以外にはあまり知られていないような、ページ プールや 非ページ プールといったリソースをピックアップして紹介させていただきたいと思います。

ページ プールと非ページ プールについて

一言で言うと、ページ アウトしないプール領域とページ アウトする事が出来るプール領域という事になりますが、言葉だけだとさっぱり分かりませんね。

そこで漠然とですが説明しますと、、

 - ページ プール

ページ プールとは、カーネル モードで動作するドライバによって確保される仮想メモリ空間で、OS コンポーネントやアプリケーションにより利用される。

ページ プールはページング ファイルへの書き出し (ページ アウト) を行うことが可能。

ページ アウトが可能なため、確保されているページ プールが全て物理メモリ上に存在しているわけでは無い。

 - 非ページプール

ページ プールとは異なり、ページ アウトが行われない領域。

となります。

ページ プール、非ページ プールの用途は多岐に渡りますが、実際にプール領域を比較的多く使用するモジュールとしては、OS モジュールのほか、I/O を処理するドライバや、ウイルス対策ソフト等に含まれるフィルタ ドライバが一般的に知られています。

そして、これらの領域は共有されているために、椅子取りゲームと同じで特定のフィルタ ドライバ等で多く確保されてしまうと、他のフィルタ ドライバで使う事ができなくなって、様々な問題が発生する可能性があります。

これらの領域が枯渇していきますと、有名なところではイベント ログでは、srv : 2019 や srv : 2020 といったイベントが記録されたり、ファイル共有にアクセスできなくなったり、システムがハングアップしてみたり etc... といろいろと不都合な現象が発生してきます。

さて、そこで気になるのがこれって最大でどのくらい使えるの？という事ですが、実は OS が 32-bit の環境と64-bit の環境では大きく違ってきます。

	32-bit	64-bit
非ページ	256 MB (/3GB 有効時は 128MB)	128 GB
ページ	491.875 MB (Windows 2000, XP)	128 GB
	650 MB (Windows Server 2003)

※ 実際には上記を最大値として、物理メモリ サイズやそのシステムにインストールされているコンポーネントなど様々な要素によって決定されます (詳しい確認方法は続編で)。

ページ プール、非ページ プールの枯渇でお悩みの方がいれば、恒久的な対策としては 64-bit のシステムを導入する事が必要だという事にお気づきになるかと思います。

実は Windows Vista および Windows Server 2008 以降の Windows についてはまた異なるのですがそれはまたおいおいご紹介いたします。

32-bit のシステムが現役で、64-bit のシステムや Windows Server 2008 にはすぐに移行できない！

というのが現実ではあると思いますので、前置きが長くなりましたが、ここではこの 2つのリソースの監視方法について、紹介をさせていただきたいと思います。

何で見るか

 

ページ プールや 非ページ プールを監視する場合には、一般的にはパフォーマンス モニタを使います。

何を見れば良いか

パフォーマンス モニタを使用する場合には、以下のカウンタを確認します。

Memory\Pool NonPaged Bytes :

非ページ プールのサイズ (バイト単位) を測定します。

Memory\Pool Paged Bytes :

ページ プールのサイズ (バイト単位) を測定します。

どう見れば良いか

正常な状態からこれらの値を監視する事で、システムの平均的な値が確認できますので、定期的に監視をして健常性を確認する事をお勧めします。

パフォーマンス状況からは、異常の可能性が高いと判断できる状況としては、以下の二つがあげられます。

・リーク (長期的な上昇傾向)

・スパイク (一時的な高負荷)

定期的に上記カウンタ値を採取いただいて、徐々に増加を続けているような場合には、そのシステムではメモリ リークが発生している可能性があります。

逆に普段増加の傾向が見られないのに、あるタイミングで急増しているような場合には、その瞬間何らかのタスクの影響で瞬間的な負荷によりシステムの健常性が保たれなくなっている可能性があります。

どう対応すれば良いか

一時的な負荷の場合には、そのタイミングで登録しているタスクを確認したり、管理ツールで行われる処理やウイルス対策ソフトでスキャンの動作が行われていないか等を確認する事で原因が追求できる場合があります。

ドライバを更新した後からパフォーマンス モニタが正常時と比べて高い値を推移するようになった！

新しく管理用のツールをインストールした後から急にシステム リソース不足のエラーが多発するようになった！

といったような場合には、まずは最新版のドライバへの更新やアンインストール、更新後であればロールバックして現象が継続するかの切り分けをすることをお勧めします。

これは動作が変更されている、もしくは既知の障害が修正されている事を期待しての対策ではありますが、初動調査としては非常に有効な切り分けではありますので、是非問題がありましたら確認してみてください。

現象が収まった場合には、管理用ツールや更新したフィルタ ドライバが影響していると判断する事が出来ますので、モジュールの提供元へご確認いただく事で原因が判明する場合があります。

パフォーマンス モニタだけでは特定できない場合は？

ここまででご紹介しましたように、一時的な負荷や現象発生時に行われているタスクがある程度特定できるような場合は良いのですが、まったく想像もできない事が多々あります。

そのような場合には、ページ プールや非ページ プールをだれが一番多く確保しているのかを確認する必要があります。

残念ながらパフォーマンス モニタではそこまでは確認できませんので、第 2 回以降では確認方法も含めてより詳細な調査方法についてをご紹介させていただきたいと思います。

 

~ 第 2 回 へつづく ~

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

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

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