リソース不足について – 番外編1 (64bit 環境での注意点)

こんにちは。

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

"リソース不足について" という内容について、以前田辺と丸山から説明させていただきました。

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

https://blogs.technet.com/askcorejp/archive/tags/_EA30BD30FC30B9300D4EB38D_/default.aspx

 今回はその番外編で、64 bit 環境でも非ページ プールなどのリソース不足が発生してしまう可能性についてお話したいと思います。

※ 下記は Windows Server 2003 の動作を中心に記述しており、Windows Server 2008 まで同様の問題が起こりえます。

※ Windows 7 / Windows Server 2008 R2 以降は、この問題も踏まえてメモリ管理のデザインが大きく変更されていますので、改善されています。

※ 該当する OS など詳細については、KB 976618 もご参照ください。

(情報更新 2011年 10月) 残念ながら、Windows Server 2008 R2 や Windows Server 2008 R2 SP1 環境でも、やはりこの問題に遭遇してしまう事が確認されました。詳細については以下もご参照ください。

Windows 7 and Windows Server 2008 R2: Do you still need the Microsoft Windows Dynamic Cache Service?

非ページ プール領域が大量に必要な状況

非ページ プールは OS のモジュールも含めた各種ドライバから利用されますが、ファイル共有のアクセスが多い環境や、VSS (Volume Shadow Copy Service)で大容量のボリュームが対象となっている環境では、非ページ プールが大量に必要となる場合があります。

特に VSS で利用される非ページ プールは、VSS の対象となっているボリュームのサイズから算出する事が可能です。

- 計算方法

VSS は、対象ボリューム 1TB 当たり、平常時で非ページ プールが 8MB 消費されます。

スナップショット作成時などのピーク時には、その 5 倍が必要となりますので、必要な非ページ プールの計算式は 対象ボリュームサイズ × 40 MB となります。

(詳細については、こちらのサイト https://technet.microsoft.com/en-us/library/cc755419(WS.10).aspx もご参照下さい)

この計算式から、5TB のボリュームを VSS の対象とした場合、VSS だけで 200MB 程度の非ページプールが必要となる事がわかります。

しかし、特に Windows Server 2003 までの 32 bit 環境は非ページ プールの最大値が 256MB ですので、VSS のために 64 bit 環境をご検討される方も多いのではないかと思います。

非ページプール上限値

では、64 bit 環境であれば、非ページ プール不足に遭遇する事は絶対ないと言えるかについて、今回はお話したいと思います。

64 bit 環境にすれば、カーネルリソースの問題は万事解決か？

上述の通り、特に 32 bit の Windows Server 2003 環境の場合、物理メモリをいくら搭載しても非ページプールの 仮想アドレス空間 の最大が 256 MB ですので、5TB のボリュームに対して VSS の利用は難しい、という点に誤りはありません。

64 bit 環境であれば、Windows Server 2003 でも 128 GB もしくは搭載物理メモリの 40% のどちらか小さい方となりますので、例えば物理メモリを 4GB 搭載している環境では非ページ プールの最大は 1.6 GB となり、非ページ プールの仮想アドレス空間のキャパシティ的には十分クリアできる事になります。

しかし、ここで一つ落とし穴があります。

上記でクリアできたのは、あくまでも仮想アドレス空間の話となります。

非ページ プールは、その名の通りページアウトの対象とはならない空間であり、全て物理メモリ上に配置される必要があります。

ここに問題が出る可能性があります。

他のアドレス空間が物理メモリを使い切る

64 bit 環境の場合、ページ プール / 非ページ プール以外にも、各種仮想アドレス空間が大幅に拡張されています。

仮想アドレス空間レイアウト (Windows Server 2003)

仮想アドレス空間の中から、処理を行う領域が物理メモリにマッピングされる事になるわけですが、この中で システム キャッシュ (システム ワーキングセット) (パフォーマンス ログでは Memory\Cache Bytes カウンタ) は、次の 5 種類のワーキングセットが合計されたサイズになります。

・システム キャッシュ ページ

・ページ プール

・Ntoskrnl.exe 内のページング可能なコードとデータ

・デバイス ドライバ内のページング可能なコードとデータ

・システム マップドビュー

システム ワーキングセットもワーキングセット (現在使用している物理メモリ領域) となりますので、実際の最大値は 128 GB か、物理メモリサイズの 90% のうちの小さい方となりますが、例えば 4GB の物理メモリを搭載している環境では、そのうちの 3.6 GB 程度を使ってしまう可能性があります。

物理メモリへのマッピング処理に失敗し、非ページプール不足となる

システム ワーキングセットで 3.6 GB 使っている場合、物理メモリ 4GB のうち残りは 400MB 程度となるわけですが、物理メモリは各プロセスなどからも利用されますので、実際には 4GB をほぼ使い切っている状況にもなり得ます。

その状況で 5TB のボリュームに対してスナップショットを実行した場合、非ページ プールの仮想アドレス空間と、物理メモリの空きとして 200MB の要求が行われれますが、処理を行った時点で空きがない状態である場合、非ページプールの確保処理は失敗となり、VSS の処理は非ページ プール不足 (リソース不足) としてエラーとなってしまう事があります。

対応策

対処方法としては、以下が挙げられます。

1. 物理メモリの増設

2. 既定では物理メモリの 90% となっているワーキングセットの上限値を下げる

十分なキャッシュを利用できる環境である事がシステム パフォーマンスの観点ではベストであるため、最初に物理メモリの増設が挙げられますが、キャッシュの特性上、空きがあれば使うという動作になります。

このため、物理メモリをいくら増設しても物理メモリをシステム ワーキングセットが使い切っている場合は、ワーキングセットの上限値を別途設けるという方法があります。

ただし、ワーキングセットの上限値は OS 標準の機能では設定できず、プログラムから SetSystemFileCacheSize 関数を利用して FILE_CACHE_MAX_HARD_ENABLE のフラグと合わせて、システム起動後に毎回設定する必要があります。

上限値の設定については、弊社からもワーキングセットの上限値をレジストリで変更でき、サービスとして動作するツールを下記にて公開しています。

Microsoft Windows Dynamic Cache Service

https://www.microsoft.com/downloads/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af&displaylang=en

- 関連情報

SetSystemFileCacheSize Function

https://msdn.microsoft.com/en-us/library/aa965240(VS.85).aspx

Article ID: 976618
You experience performance issues in applications and services when the system file cache consumes most of the physical RAM
https://support.microsoft.com/kb/976618/en-us
https://support.microsoft.com/kb/976618/ja (機械翻訳)

Windows 7 and Windows Server 2008 R2: Do you still need the Microsoft Windows Dynamic Cache Service?

https://blogs.technet.com/b/yongrhee/archive/2010/02/16/windows-7-and-windows-server-2008-r2-do-you-still-need-the-microsoft-windows-dynamic-cache-service.aspx