Windowsメモリの深層(第2回) ── 物理ページの一生:5つのリストとページファイルの真実

前回の「Windowsメモリの深層(第1回) ── 仮想アドレスが物理RAMに変わる瞬間」では、Commit済みページへ初めて触れた瞬間、ページフォルトハンドラーが物理ページを割り当てるところまで追いました。

では、その物理ページがWorking Setから外された後は、どこへ行くのでしょうか。

「ページファイルへ追い出される」と一言で済ませる説明をよく見ますが、実際にはその前後に複数の状態があります。

変更されていないページは、内容を残したままStandbyへ移れます。

変更済みページは、まずModifiedで書き戻しを待ちます。

再利用時にはFreeやZeroedを経由し、同じ内容が必要になればStandbyからソフトフォルトで復帰できます。

本記事では、PFNデータベースを軸に、1枚の物理ページがActive、Modified、Standby、Free、Zeroedをどう移動するかを追います。

数字の読み方は導入編「Windowsの『メモリ使用量』は何を表しているのか」を前提にします。

「Windowsメモリの深層」全3回

1. 第1回:仮想アドレスとページフォルト
   Commit済みの仮想ページが、いつ物理RAMを得るかを追います。
2. 第2回(本記事):物理ページの一生
   Working Setから外れたページの状態遷移とページファイルの役割を追います。
3. 第3回:セクションオブジェクトとコピーオンライト
   DLL、ファイルマッピング、共有メモリが物理ページを共有する仕組みを追います。

第2回が答える疑問は、次の1つです。

Working Setから外れた物理ページは、消えるのか、ディスクへ行くのか、それともRAMに残るのか。

対象読者は、Availableが多いのにStandbyも多い理由、Working Setトリミング後の挙動、ページファイル設定、メモリ圧縮を仕組みから理解したい開発者・運用担当者です。

前提環境はWindows 10/11または現行のWindows Server、前提知識はWorking Set、Commit、ソフト／ハードフォルトの基礎です。

難易度は中級です。PFNやページリストという内部用語を使いますが、カーネルデバッガーなしでもRAMMapとPerfMonで観測できる範囲を中心にします。

1. まず結論

最初に、誤解しやすい点をまとめます。

• Working Setから外れたページは、すぐ消えるとは限りません。
  cleanなページはStandbyに残り、同じ内容が必要ならディスクを読まずに戻れます。
• 変更済みページは、すぐ再利用できません。
  privateな内容ならページファイル、マップドファイルなら対応するファイルなどへ書き戻せる状態にしてから再利用します。
• AvailableにはStandbyが含まれます。
  Standbyは内容を保持したキャッシュであると同時に、必要なら即座に奪える再利用候補です。¹
• ページファイルへの書き出しは、RAMが完全に尽きてから始まる一括処理ではありません。
  Modifiedリストとメモリ圧力に応じ、バックグラウンドで進みます。²³
• ページファイルは「遅いRAM」だけではありません。
  Commit Limitを広げ、変更済みプライベートページのバックストアになり、クラッシュダンプを支えます。⁴
• ページファイルを無効にしても、メモリリークは直りません。
  Commit Limitが下がり、RAMを有効利用する選択肢とダンプ取得能力を減らすことがあります。

一文でまとめるなら、Windowsはページを捨てる前に、再び必要になる可能性と、元の内容を復元できる場所を確認している、です。

2. PFNデータベース ── 物理RAM側の台帳

第1回で見たPTEは、仮想ページから物理ページへの変換を表しました。

物理ページ側から「このRAMページは何に使われているか」を追う台帳が、PFNデータベースです。

PFNはPage Frame Numberの略で、物理RAMをページ単位に番号付けしたものです。

PFNエントリーは概念的に、次の情報を追います。

• 物理ページの現在状態
• 参照数や共有数
• 対応するPTE
• 変更済みかどうか
• どのページリストに属するか
• NUMAノードや優先度に関わる情報

WinDbgの!pfnは特定PFNの情報を、!memusageは物理メモリの利用状況と各ページリストの集計を表示します。⁵⁶

RAMMapは、同じ世界をカーネルデバッガーなしで観測するためのSysinternalsツールです。Use Countsでは用途とページリスト、Priority Summaryでは優先度別Standby、Physical Pagesではページ単位の利用状況を見られます。⁷

3. 5つの状態を一枚につなぐ

本記事では、物理ページの流れを次の5状態で簡略化します。

厳密には、現行Windowsには優先度別Standby、Transition、Badなど、ここに描かない状態やリストがあります。またActiveは単一の「Activeリスト」というより、有効PTEを通じてWorking Setなどから参照中の状態です。

それでも、アプリのメモリ挙動を読むには次の図が有効です。

図1: Working Setで参照中のページが、cleanならStandby、dirtyならModifiedへ移る。同じ内容なら復帰し、別用途なら直接再利用するか、ゼロが必要な割り当てに備えてFree／Zeroedを経由する。

この図の重要点は、Working Setから外れることと、内容が失われることが同じではない点です。Standbyページを別用途へ奪う場合も、必ずFree／Zeroedを順に経由するわけではありません。新しいデマンドゼロのプライベートページとしてユーザーモードへ渡すなら古い内容を消す必要がありますが、ファイル内容の読み込み先などページ全体を上書きする用途なら、Standbyの識別を外して直接再利用できます。

4. Active / Valid ── 今、参照できる物理ページ

Active/Validなページは、有効なPTEを通じてプロセスのWorking Setやシステム空間から参照されています。

CPUは通常のアドレス変換で到達できるため、そのアクセス自体にはページフォルトが不要です。

ページがActiveであり続けるかは、固定ではありません。

メモリマネージャーは利用可能メモリを維持するため、Working Setの大きさやページの最近の利用状況などを見て、候補ページをトリムします。MicrosoftのWorking Set解説も、利用可能メモリを作るためメモリマネージャーがWorking Setからページを削除すると説明しています。⁸

4.1. トリムは解放ではない

Working Setトリミングで変わるのは、主に今すぐ有効PTEで参照できる常駐状態です。

次は別々の出来事です。

• Working Setから外す
• Commitを解放する
• 仮想アドレス範囲を解放する
• 元データを失う

EmptyWorkingSetやツールの「Trim Working Set」を実行しても、VirtualFreeやヒープ解放の代わりにはなりません。

同じページへ再び触れれば、Standbyからのソフトフォルト、またはバックストアからのハードフォルトで戻ります。

したがって「Working Setを小さくできた」ことは、「リークを直した」ことを意味しません。

5. cleanページはStandbyへ行く

ページがWorking Setから外されても、内容が元ファイルと同じ、またはすでに安全なバックストアを持つなら、Standbyへ置けます。

代表例は次のとおりです。

• 変更されていないEXE/DLLのコード
• 変更されていないメモリマップトファイル
• 書き戻し済みのプライベートページ
• ファイルキャッシュに残るデータ

Standbyページは、以前の内容と対応関係を保っています。

同じプロセスや別プロセスがその内容を必要としたとき、まだ再利用されていなければ、PTEを再接続するソフトフォルトで戻せます。

一方、別の割り当てが物理ページを必要とすれば、Standbyの古い識別を捨てて再利用できます。再利用先がゼロ初期化を必要とするユーザーモードのプライベートページならZeroedを用意しますが、ファイル内容などでページ全体を上書きする用途では、ゼロ化せず直接再割り当てできます。

この二面性から、Standbyはキャッシュであり、Availableでもあるのです。

5.1. AvailableにStandbyが入る理由

MEMORYSTATUSEX.ullAvailPhysは、ディスクへ書き出さず直ちに再利用できる物理メモリであり、Standby、Free、Zeroedの合計です。¹

したがって、タスクマネージャーで次のように見えても矛盾ではありません。

• Freeは少ない
• Cached/Standbyは多い
• Availableは十分ある

Windowsは空きRAMをただ放置せず、最近使ったファイルやコードをStandbyへ残します。

必要になればキャッシュとして高速に再利用し、別用途が必要なら奪えます。

「Freeが少ないから即メモリ不足」と判断せず、Available、Commit、ハードフォルト、処理遅延を合わせて見ます。

6. dirtyページはModifiedで待つ

アプリがページへ書き込むと、その内容は元のバックストアと一致しなくなります。

このdirtyページを、そのまま別用途へ上書きするとデータを失います。

Working Setから外された変更済みページは、Modifiedで書き戻しを待ちます。

書き戻し先はページの種類で変わります。

Microsoftのページファイル解説も、すでにディスク上に存在する.dll、.exe、通常ファイルはページファイルへ重ねて書く必要がなく、元のディスクコピーを持たない変更済みデータがページファイルの候補になると説明しています。²

6.1. Modified Page Writer

Modified Page Writerは、メモリマネージャーが追跡するページファイルバックのdirtyページを走査し、ページファイルへ書き出すシステムワーカーです。³

マップドファイル側にはMapped Page Writerなどの経路があり、ファイルシステムやキャッシュマネージャーと協調して対応ファイルへ書き戻します。

重要なのは、書き出しが「RAMが0バイトになるまで何もしない」方式ではないことです。

WindowsはModifiedリスト、Available、ページファイルの状態などに応じ、将来再利用できるページをバックグラウンドで準備します。

書き戻しが終わり、ほかに有効参照がなければ、ページは内容を保ったStandbyへ進めます。

6.2. ページ出力とページファイル固有のI/Oを分ける

次のカウンターを混同しないでください。

• Memory\\Page Writes/sec: 物理メモリを空けるために発行されたページング書き込みI/Oの回数
• Memory\\Pages Output/sec: その書き込みでディスクへ出されたページ数
• Memory\\Page Reads/sec: ハードフォルト解決のために発行されたディスク読み取りI/Oの回数
• Memory\\Pages Input/sec: その読み取りでRAMへ入ったページ数

Page Writes/secとPages Output/secは、ページファイルだけを識別するカウンターではありません。マップドファイルなど、ファイルバックのdirtyページを書き戻す経路でも増え得ます。逆に、入力側もページファイル、DLL、EXE、メモリマップトファイルを区別しません。²

pagefile.sys固有のI/Oを特定したい場合は、この4カウンターだけから推定せず、ETW/WPAでFile I/OとDisk I/Oを記録し、FileObjectとFileNameを対応付けて対象ファイルを確認します。⁹

ページファイルへ先に書いておくことは、すぐディスクから読み戻すことを意味しません。

アクセスされなければ、書き戻し済みページをRAMから外して、より頻繁に使うページへ物理メモリを回せます。

7. Standby、Free、Zeroedの違い

7.1. Standby

以前の内容と対応関係を保持しています。

• 同じ内容が必要ならソフトフォルトで戻せる
• 別用途に必要なら古い識別を破棄して再利用できる
• 優先度別のStandbyリストがある

7.2. Free

以前の内容との有効な対応関係は失われ、割り当て可能ですが、ページ内には古いビット列が残り得ます。

ユーザーモードへそのまま渡すと、以前のプロセスの情報を漏らす危険があります。

7.3. Zeroed

内容がゼロで、ユーザーモードの新規ページへ安全に渡せます。

第1回のデマンドゼロフォルトは、利用可能なZeroedページを得てPTEへ結ぶ代表例でした。

FreeからZeroedへの準備は、需要とシステム状態に応じて行われます。

このため「Free」と「Zeroed」はどちらも空きに見えても、セキュリティ上の準備状態が違います。

8. メモリ圧縮ストア ── RAM内にもう1つの行き先を作る

Windows 10以降のメモリマネージャーは、メモリ圧力があると、使用頻度の低いページをすぐディスクへ書く代わりにRAM内で圧縮できる場合があります。

圧縮ページの集合がcompression storeです。Windows 10の初期実装ではSystemプロセスのWorking Set内に計上されていましたが、現行Windowsではデバッグツールのプロセス一覧に専用のMemory Compressionプロセスとして表示されます。したがって、現在の圧縮量を調べるときにSystemプロセスのWorking Setだけを追ってはいけません。圧縮によってより多くのアプリを物理メモリへ保ち、ディスクI/Oを減らすという目的は変わりません。¹⁰¹¹

ただし、次のように理解してください。

• 圧縮ページもRAMを使う
• 圧縮・展開にはCPUコストがある
• 圧縮してもCommitの約束は消えない
• 必ず「圧縮してからページファイル」という固定順序ではない
• ページの種類、圧力、アクセス履歴に応じて方針は変わる

タスクマネージャーの「使用中(圧縮)」は、圧縮によって物理メモリが完全に空いたという意味ではありません。

圧縮ストアは、ページファイルを不要にする機能ではなく、RAMとストレージの間にCPUを使ってI/Oを減らす選択肢を加えたものです。

9. ページファイルの本当の役割

ページファイルには、少なくとも3つの役割があります。

9.1. Commit Limitを広げる

システムのCommit Limitは、概ねRAMと全ページファイルの合計で決まります。

ページファイルをなくすと、Commit Limitは搭載RAMより少し小さい水準まで下がります。Commit Totalが上限へ達すると、新しいCommitが失敗し、アプリの異常終了やシステム不調につながり得ます。⁴

これは「今pagefile.sysへ何GB書いているか」とは別の話です。

ページファイルは、Commitという約束を支える上限側の余力でもあります。

9.2. 変更済みプライベートページを支える

アクセス頻度の低い変更済みプライベートページをページファイルで支えれば、その物理ページをRAMから外し、頻繁に使うコードやデータへ回せます。⁴

ページファイルを無効にすると、こうしたページをRAMから外す選択肢が減ります。

「ページアウトが起きないから速い」と単純には言えません。

9.3. システムクラッシュダンプを支える

システムクラッシュ時にMemory.dmpを作るには、選択したダンプ方式を支えられるページファイルまたは専用ダンプファイルが必要です。²

完全メモリダンプ、カーネルメモリダンプ、自動メモリダンプでは必要量が異なります。

クラッシュ調査を行う環境では、容量節約だけを理由にページファイルを消すと、最も必要なときに証拠が残らないことがあります。

収集方式は「Windowsアプリのクラッシュダンプ収集入門」も参照してください。

10. 適正サイズは一律ではない

「RAMの1.5倍」などの固定式だけで決めるべきではありません。

Microsoftは、ページファイルの適正サイズは次の2点でシステムごとに異なり、一般化できないと説明しています。²

1. ピーク時のSystem Commit Charge
2. 必要なシステムクラッシュダンプ

実務では、次の順で考えます。

10.1. まずシステム管理を基準にする

Windowsの既定はシステム管理です。

搭載RAM、Commitの需要、クラッシュダンプ要件などに応じて増減します。特別な制約や測定結果がないなら、ここから始めるのが安全です。

10.2. 代表負荷でピークCommitを測る

PerfMonで次を長期間収集します。

• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\% Committed Bytes In Use
• Memory\\Modified Page List Bytes
• Paging File(*)\\% Usage
• Memory\\Available MBytes
• Memory\\Page Reads/sec
• Memory\\Page Writes/sec

月末処理、バックアップ、ビルド、複数ユーザー同時利用など、実際のピークを含めます。

ページファイル使用率が高いことだけで、ストレージ性能問題とは断定できません。ただし、上限へ張り付く状態は容量不足の警告です。Commitが上限へ迫っているか、Modifiedが大量に待っているか、ディスクが飽和しているかを合わせて見ます。²

10.3. ダンプ要件を先に決める

完全メモリダンプが必要か、カーネルメモリダンプで十分か、専用ダンプファイルを使うかを決めます。

固定サイズへ変更するなら、ピークCommitだけでなくダンプ要件も満たす必要があります。

11. 自分の目で確かめる

11.1. RAMMapでページリストを見る

RAMMapを管理者として起動し、まずUse Countsを開きます。⁷

見る項目は次です。

• Active
• Standby
• Modified
• Modified no write
• Free
• Zeroed

Priority Summaryでは、Standbyが優先度別に分かれていることを確認できます。

Processesでは各プロセスのWorking Set、File SummaryとFile DetailsではRAM内にあるファイルデータを追えます。

大きめのローカルファイルを一度読み、読み取り処理を終了してRefreshすると、そのファイルのページがFile SummaryやStandby側に残る場合があります。

同じファイルをもう一度読むと、再利用されていないページはディスクI/Oなし、または少ないI/Oで復帰できます。

メモリ圧力、ウイルス対策、ファイルサイズで結果は変わるため、1回の数値より状態遷移を見ます。

RAMMapのEmptyメニューはシステム状態を人為的に変えます。本番機の性能改善操作としてStandbyを消すのではなく、隔離した検証環境だけで使ってください。

11.2. TestlimitでCommitとTouchを分ける

Testlimitは、メモリ、ハンドル、プロセス、スレッドなどのリソース不足を模擬するSysinternalsツールです。まず、手元のバイナリで次を実行し、表示されるバージョンとusageを確認します。

.\\testlimit64.exe -?

以下はTestlimit v5.24を対象にします。v5.24の公式構文では、-m [MB]が指定量のメモリ確保、-d [MB]が確保とTouch、-e [seconds]が割り当て間隔、-c [count]が割り当て回数です。-cは最後に指定します。手元の表示が異なる場合は、そのusageを優先してください。¹²

次に、使い捨てVMで小さく試します。

# -m 64: 64 MiBを確保、-e 1: 1秒間隔、-c 8: 8回で停止
.\\testlimit64.exe -m 64 -e 1 -c 8

# 同じ回数・間隔で、-dにより各領域をTouchする
.\\testlimit64.exe -d 64 -e 1 -c 8

次を同時に記録します。

• Task Managerの「コミット済み X/Y」
• RAMMapのActive、Modified、Standby
• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\Available MBytes
• Memory\\Modified Page List Bytes

Commit枯渇を実際に再現する場合は、ホストPCでは行わず、スナップショットを取ったVMで回数を段階的に増やします。

上限まで自動で確保させる実行は、画面停止、プロセス異常終了、ログ欠損を起こし得ます。目的はOSを不安定にすることではなく、Commit Limitへ近づくと新規Commitが失敗することを観測することです。

12. 実務で避けたい4つの誤読

12.1. 「Standbyが多いからメモリリーク」

Standbyは再利用可能なキャッシュで、Availableに含まれます。

リークは、プロセス固有Commitのベースラインや割り当て内訳が負荷終了後も増え続けるかで判断します。

12.2. 「Working Setを削ればリークが直る」

トリムは常駐状態を変えるだけで、Commitや仮想割り当てを解放しません。

再アクセスすればフォルトして戻ります。

12.3. 「ページファイル使用量が0なら不要」

ページファイルは現在の書き込み量だけでなく、Commit Limitとクラッシュダンプを支えます。

平常時の使用量だけで削除を決めると、ピーク時の余力と障害時の証拠を失います。

12.4. 「メモリ圧縮が先、次に必ずページファイル」

圧縮は固定された直列パイプラインではありません。

ページの種類、圧縮効率、CPU負荷、メモリ圧力、バックストアの有無に応じて、Windowsが動的に選びます。

13. まとめ

• PFNデータベースは、物理ページの所有、参照、変更、ページリスト状態を追う台帳です。
• Working Setから外れたcleanページはStandbyへ残り、同じ内容が必要ならソフトフォルトで復帰できます。⁸
• dirtyページはModifiedで待ち、プライベートページならページファイル、マップドページなら対応ファイルなどへ書き戻されます。³
• AvailableはStandby、Free、Zeroedの合計で、Standbyが多いこと自体はメモリ不足ではありません。¹
• メモリ圧縮はRAM内でページを圧縮してI/Oを減らしますが、Commitとページファイルの役割を消しません。¹⁰
• ページファイルはCommit Limit、変更済みプライベートページ、システムクラッシュダンプを支えます。⁴²
• 適正サイズはピークCommitとダンプ要件で決まり、一律の倍率では決められません。²
• Working SetトリミングやStandby消去は、メモリリーク修正ではありません。

続きは第3回「セクションオブジェクトとコピーオンライト:DLLとファイルマッピングの正体」です。

Standbyへ残るファイルページやDLLが、複数プロセスからなぜ同じ物理ページとして見えるのかを追います。

関連記事

• Windowsメモリの深層(第1回) ── 仮想アドレスが物理RAMに変わる瞬間
• Windowsの「メモリ使用量」は何を表しているのか
• Windows I/Oの深層(第4回) ── キャッシュマネージャーとWriteFile
• Windowsアプリのクラッシュダンプ収集入門
• Process Explorer / Handle / VMMap実践

関連する相談領域

合同会社小村ソフトでは、Windowsアプリケーションのメモリ圧迫、Commit枯渇、ページング、Working Set増加、クラッシュダンプ取得設計の調査を扱っています。

• Windowsアプリ開発
• 不具合調査・原因解析
• 既存資産活用・移行支援
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Working Setから外れたページは、すぐページファイルへ書かれますか？

いいえ。変更されていないページは内容を保ったままStandbyへ移り、すぐ再利用できるキャッシュになります。変更済みページはModifiedへ移り、必要に応じてページファイルまたは対応するファイルへ書き戻された後、Standbyなどの再利用可能な状態へ進みます。

タスクマネージャーのAvailableにはStandbyメモリが含まれますか？

含まれます。Windowsが報告する利用可能物理メモリは、Standby、Free、Zeroedの合計です。Standbyは古い内容を保持していますが、必要なら即座に別用途へ再利用できるため、利用可能メモリとして数えられます。

ページファイルへの書き出しは、RAMが完全に尽きてから始まりますか？

いいえ。WindowsはModifiedリストや利用可能メモリの状態に応じ、アクセス頻度の低い変更済みページをバックグラウンドで書き戻します。絶対的な枯渇を待って一斉に退避する単純な仕組みではありません。

ページファイルを無効にするとWindowsは速くなりますか？

一般には速くなると断定できません。無効化するとCommit Limitが下がり、アクセス頻度の低い変更済みページをRAMから外しにくくなり、システムクラッシュダンプにも影響します。通常はシステム管理のまま、ピークCommitとダンプ要件を測って判断します。

メモリ圧縮があればページファイルは不要ですか？

不要にはなりません。圧縮ストアはRAM内でページを圧縮してI/Oを減らす仕組みですが、圧縮ページも物理メモリを使い、Commitの保証を置き換えません。圧縮とページアウトの選択はメモリマネージャーの動的な方針です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。