Windows Server 2019を運用していると、Paged Poolのメモリ使用量が徐々に増え続け、最終的に応答が止まったりクラッシュを引き起こしたりするケースが報告されています。これはシステム管理者にとって厄介な問題ですが、原因となるドライバーの特定、Windowsの更新プログラム適用、レジストリ設定など、複数の対処策を組み合わせることで、リスクを大幅に低減できる可能性があります。この記事では、Paged Poolが膨れ上がる背景や原因を探りつつ、具体的な対策例を詳しく解説していきます。
Windows Server 2019のPaged Pool問題とは
Paged Poolとは、カーネルモードで動作するコンポーネントが使用するメモリ領域のひとつであり、ページングファイルへの書き出しが可能なプール領域を指します。Windows Server 2019に限らず、Windows系OS全般で使われていますが、特定のドライバーやサービスによるメモリリークが起こると、Paged Poolが不必要に占有され続け、システム全体のパフォーマンスが低下する要因となります。
Paged PoolとNon-Paged Poolの違い
- Paged Pool
ページングファイルにスワップできる領域。OSが状況に応じてメモリの内容をディスクへ退避できるため、より柔軟なメモリ管理が期待できます。ただし、メモリリークや異常増加が起こると、システム全体がスローダウンしやすくなります。 - Non-Paged Pool
常に物理メモリ上に確保される領域。ドライバーやカーネルが絶対にディスクへページアウトできないデータを扱う際に使用されます。Non-Paged Poolが枯渇すると深刻な状態に陥りますが、Paged Poolであっても膨大に消費されると最終的にはシステムの不安定化を招きます。
原因の特定方法
Paged Poolが膨らむ原因は、ドライバーやカーネルレベルでのメモリリークであることが多いです。特にHyper-V関連や、クラウド環境（例: Azure）の仮想マシン上で稼働している場合は、特定のドライバーが原因となる事例が報告されています。
Windows Performance Recorder (WPR) と Windows Performance Analyzer (WPA)
- WPR
コマンドラインおよびGUIで動作する強力なトレースツールです。システム内部のイベントを詳細に記録し、そのデータをもとにWPAで解析できます。
wpr -start GeneralProfile -filemode
# 一定時間トレースした後
wpr -stop C:\trace.etl- WPA
WPRで取得したトレースファイル（.etl）を読み込み、どのプロセスやドライバーがメモリを大量に消費しているかを可視化できます。カーネルメモリやユーザーメモリなど、詳細な内訳をグラフやリストで分析できるため、原因究明に役立ちます。
RAMMap (Sysinternals) の活用
MicrosoftのSysinternalsツールであるRAMMapを使うと、現在の物理メモリの使用状況を多角的に確認できます。Paged PoolとNon-Paged Poolの利用量、ファイルキャッシュやプロセスごとのワーキングセットなど、リアルタイムに近い状態でチェックが可能です。RAMMapの「Use Counts」タブを見ると、Paged Poolがどのくらい利用されているかひと目で把握できるため、異常増加の兆候を掴みやすくなります。
RAMMapによる簡単な解析手順
- RAMMapを起動
- 管理者権限で実行することで、より正確な情報を取得可能です。
- 「Use Counts」タブを確認
- Paged Poolの欄を確認し、総合計やセグメントごとの使用量をチェックします。
- 「File Summary」や「Processes」タブを併用
- ファイルごとのメモリ使用量やプロセス単位の詳細を追うことで、怪しいドライバーやサービスを洗い出すヒントとなります。
最新の更新プログラム適用による対策
Windows Server 2019の累積更新プログラムやサービススタック更新プログラムには、メモリリーク関連の修正が含まれることがあります。特にAzure環境でSM00ドライバーなどが原因となるケースや、Hyper-V環境特有の問題が報告されている場合、Microsoftが後日修正パッチをリリースすることがあります。
- Windows Updateを常に最新の状態に保つ
- 月次のパッチ（Bリリース）だけでなく、C/Dリリースのプレビュー更新プログラムもウォッチし、適用可能か検討します。
- サービススタック更新プログラム (SSU) の適用
- 一部の累積更新プログラムを適用するには、事前にSSUを更新しておく必要がある場合があります。
- Microsoft Updateカタログの活用
- 不具合が明確で、必要なパッチが限定的である場合は、Microsoft Updateカタログから手動ダウンロードしてテスト環境で検証する手段もあります。
実際に、「2025年1月の累積更新プログラム」でPaged Poolが増え続ける問題が解消されたというレポートも存在します。こうした事例からも、まずは最新の更新プログラムを適用し、問題が再現するかどうか検証することが重要です。
レジストリでのPaged Pool制限
Paged PoolはWindowsが動的に管理しますが、場合によってはレジストリを調整し、最大サイズを制限できる可能性があります。ただし、レジストリ変更は動作に大きな影響を与える恐れがあるため、十分なテストを行ってから運用環境に適用してください。
SystemPtesLimitの設定例
以下は、Paged Poolの制限を試す際に用いられるレジストリキーの一例です。
レジストリパス:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management- SystemPtesLimit
物理アドレス拡張 (PAE) が有効な64ビットシステムでは、理論上の上限が大きいため、OSが自動で大きめに設定します。これを手動で小さめに指定すると、メモリリークを引き起こすドライバーに対する“バッファ”を狭めることができますが、本来必要なPaged Poolまで足りなくなるリスクもあります。
レジストリ変更時の注意点
- バックアップの取得
- 変更前にレジストリのエクスポートを行い、万一の復元に備えます。
- テスト環境での検証
- 本番サーバーでいきなり実行するとダウンタイムが発生する可能性があるため、検証環境で長期動作させ、Paged Pool挙動の安定度を確認します。
- アプリケーションやドライバーの要件確認
- 特に大規模なファイルキャッシュを使うアプリケーションや、特殊なドライバーを使用する場合は注意が必要です。
Known Issue Rollback (KIR)の活用
Windows Updateの一部で、特定のパッチが原因となりメモリリークが発生していると判明した場合、MicrosoftはKnown Issue Rollback (KIR)と呼ばれる仕組みを提供している場合があります。KIRを適用すると、問題箇所のみをリバート（巻き戻し）し、根本的な修正版パッチがリリースされるまでの一時的な回避手段として機能します。
- KIR適用の流れ
- 対象となる更新プログラムが公開されているかをMicrosoft公式ドキュメントで確認します。
- 組織規模のWindows Update管理には、グループポリシーやWSUS等を利用し、KIRを展開することが可能です。
- 最終的には修正版を適用
- KIRはあくまで一時的な回避策であり、メインストリームのパッチサイクルで修正版がリリースされた際には、速やかにアップデートを行う必要があります。
システムリソースを継続的に監視する手段
Paged Poolの問題が起こるときは、Non-Paged Poolや他のリソース（CPU、ディスクI/Oなど）にも影響が及ぶ場合があります。定期的な監視体制を整えれば、問題を未然に発見し、重大な障害を回避する確率が高まります。
Performance Monitor (パフォーマンスモニター) の構成例
Windows Serverに標準搭載されているPerformance Monitorを使えば、以下のようなカウンターを監視できます。
| カウンター名 | 目的 |
|---|---|
| Memory\Pool Paged Bytes | Paged Pool領域がどれほど使用されているかを確認 |
| Memory\Pool Nonpaged Bytes | Non-Paged Pool領域の監視 |
| Process(＊)\Working Set | 各プロセスのワーキングセットサイズを監視 |
| PhysicalDisk\% Disk Time | I/Oボトルネックやスワップ状況の確認 |
| Processor(_Total)\% Processor Time | CPUリソースの逼迫状況の把握 |
これらのカウンターを一定間隔でログとして収集し、異常値を検知した際にアラートを出す運用を行えば、手動監視の漏れを防ぐことができます。またサードパーティーツールやクラウドの監視サービスを組み合わせることで、より高度なレポーティングや傾向分析が可能となります。
イベントログの活用
- Systemログ
ドライバーの読み込み失敗やクラッシュダンプの生成など、OSレベルの重大なエラーを記録。 - Applicationログ
特定のアプリケーションがPaged Poolを大量に消費している場合、そのアプリケーションでエラーが発生していないか確認する。 - Microsoft-Windows-Kernel-Memory Diagnostic/Operational
詳細なメモリ情報を提供することがあるため、必要に応じてログを有効化すると原因追跡に役立ちます。
再起動を最小限に抑える方法
Paged Poolの問題が深刻化すると、最終的にはサーバーを再起動せざるを得ない状況に陥ることが多いです。再起動はサービス停止を伴うため、運用上のリスクが高くなります。そこで、定期的なサービスの再起動やドライバーのアンロードによってメモリを解放できないか検討する価値があります。
- 問題ドライバーを特定して停止・再起動
- 例えば、特定のドライバーがPaged Poolを開放しないまま使い続けている場合、そのドライバーを再起動するだけで一定のメモリが解放される可能性があります。
- ただし、システムの重要な部分に関わるドライバーの場合は、単体での再起動が難しいケースもあります。
- サービスの再起動タスクを計画
- Windowsのタスクスケジューラを用いて、夜間や運用に影響が少ない時間帯に、特定のサービスを定期的に再起動する方法があります。
- 長期連続稼働が求められるサーバーでも、サービス単位の再起動でメモリ使用量をリセットし、週単位の再起動間隔を伸ばせる可能性があります。
- プロセス分離の検討
- もしリソースを大量に消費するアプリケーションが複数あるなら、コンテナ化や別の仮想マシンに分割して配置することで、1台あたりのメモリ負荷を分散させる方法も考えられます。
具体的な対応策をまとめた一覧
以下に、Paged Poolリーク問題への対処法を簡単にまとめた表を示します。
| 対策項目 | 内容 | メリット | リスク・注意点 |
|---|---|---|---|
| ドライバーの特定・更新 | WPR/WPA・RAMMapで過剰消費の原因を調査し、最新ドライバーやパッチを適用 | 根本原因の排除につながる | ドライバー更新で別の不具合が発生する可能性 |
| Windows Updateの適用 | 累積更新プログラムやSSUを常に最新にする | 既知の不具合・メモリリークが修正される | 更新不備による別の障害リスク |
| Known Issue Rollback (KIR) | 既存の更新プログラムで発生した不具合をロールバック | 一時的に問題を回避可能 | 根本対応でなく、最終的には修正版が必要 |
| レジストリの調整（SystemPtesLimitなど） | Paged Poolの上限を制限してリークを抑制 | 一定以上のメモリ使用を抑える可能性 | 運用に影響大、十分なテストが必須 |
| サービスの部分的な再起動、定期的な再起動のスケジューリング | サーバー全体を落とさずにメモリを解放 | ダウンタイム最小化 | 根本問題の解決にはならない |
| パフォーマンスモニター・イベントログの継続的監視 | Paged Pool/Non-Paged Pool、CPU、ディスクI/Oなどを常に監視 | 異常検知が早期化し、障害対応がスムーズ | 監視運用コストが増加 |
まとめ
Windows Server 2019でPaged Poolが大量に消費される問題は、一度発生すると深刻なパフォーマンス劣化やシステムクラッシュを引き起こすため、安定稼働を目指すうえで非常に重要なトラブルシューティング項目となります。まずはWindows Updateで最新の状態に保ち、ドライバーのバージョンを見直すことがスタートラインです。そのうえで、原因解析をツール（WPR/WPA、RAMMapなど）で徹底的に行い、問題の根本を取り除くことが長期安定稼働には欠かせません。
また、一時的な回避策としてKnown Issue Rollback (KIR)やレジストリの調整、サービス単位の再起動などを実施しつつ、常にシステムリソースを監視して早めの対処を心掛けることが望ましいでしょう。継続的な監視と柔軟な運用体制があれば、たとえメモリリークが起きたとしても重大障害に発展する前に未然に対処できる確率は大幅に高まります。最終的には、OSやドライバーが修正されるのを適用し、正常な状態を維持できるようにすることがゴールとなるはずです。
コメント