ページテーブルが大量のメモリを使用するのはなぜですか？

私の64ビットWindows 7 PCは非常に遅いです。タスクマネージャーで、メモリの使用率がほぼ100％であることに気付きました。ただし、各プロセスで報告される使用量の合計は6GBになりません（Firefoxでは約500MB、残りははるかに少なくなっています）。RAMMapをダウンロードしたところ、ページテーブルがかなりの量のメモリ（2.5GB）を占めていることがわかりました。

私はこれをググってどこにも行きませんでした-どうやらページテーブルは断片化する可能性があります。明らかに、マシンを再起動し、それが役立つかどうかを確認します。しかし、それを修正するより良い方法はありますか？

編集：再起動し、ページテーブルが30MBになりました。

編集2：数日の稼働時間の後、ページテーブルの使用は再び忍び寄っています。この回答の@ magicandre1981の指示に従って、ページテーブルの使用法のソースを見つけました。残念ながら私は空白を描きました-ページテーブルは「不明」によって使用されています！

誰もが明るいアイデアを持っていますか？

質問へのコメント、特に「ページテーブル」と「ページファイル」の混乱にコメントする必要があります。これは答えではありませんが、コメントを入力できるスペースに収まりません。

「ページテーブル」は確かにページファイルとは非常に異なります。持つn個のページ・テーブルのために使用されるRAMのMBは、使用しているという意味ではありませんNページファイルスペースのメガバイト また、一部のページテーブルエントリ（ページテーブルを構成するPTE）はページファイルの内容を参照しますが、すべてを参照しているわけではありません。

ページテーブルはメモリ内の構造であり、CPUのMMUが仮想アドレス（ページファイルではない）から物理アドレスへのアドレス変換を実行するために使用され、OSが仮想アドレススペースを追跡してページフォールトの解決を支援するために使用されます。ページテーブルは、ページテーブルエントリ（PTE）で構成されます。各PTEは8バイトを占有し、4Kバイトの仮想アドレス空間、つまり1つの仮想ページを定義します。大まかに言って、仮想アドレス空間の非空きページごとに1つのPTEがあります。

ちなみに、ページファイルは外部と内部の両方で断片化する可能性がありますが（前者は通常それほど問題ではありません。後者は必要なサイズの約4倍にすることで改善できます）、ページテーブルはできません。彼らはすでに常に断片化されており、それは少しでも問題ではありません。

各PTEには「有効な」ビットがあります。「有効」または「常駐」ページの場合、PTEには、PTEに関連付けられている仮想ページ番号に対応する物理ページ番号が含まれます。これはMMUによって直接使用されます。

「無効な」ページの場合、MMUはページ違反を発生させ、PTEには多くの可能なフォーマットと解釈があります。

注：上記のすべては、x86 / x64でページングを有効にするすべてのオペレーティングシステムに適用されます。以下は主にWindowsに固有のものですが、実装の詳細が異なる他のOSにも多くの概念が適用されます。

ページキャッシュ内のページの場合、PTEには物理ページ番号が含まれています。RAMから失われ、ページファイルに書き込まれたページの場合、PTEには、ページファイル番号と、ページの内容が書き込まれたページファイル内のオフセットが含まれます。他に考えられるPTEの内容は、仮想アドレス記述子への参照、「プロトタイプPTE」への参照、要求ゼロページへの参照などですが、これについては触れません。一部のPTEのみがページファイル内の場所を参照していると言えば十分です。

ページファイルとページテーブルは関連していますが、まったく同じものではないことを示すために、これらすべてを主に述べています。

ページテーブルはツリー構造に編成されます。プロセスごとに、このような異なるツリー、またはページテーブルのコレクションがあります。これにより、各プロセスが仮想アドレス空間の独自のインスタンスを定義できるようになります。ツリーのルートにあるページテーブルは、常にRAM内になければなりません。その他はページング可能です。それらは、未定義またはフリーの仮想アドレス空間の大きな（最小2 MB）領域に対応する場合でも存在しません。

ツリーの「葉」にあるテーブルのページテーブルエントリは、仮想アドレス空間のページに対応しています。上位レベルのテーブル（ルート（およびルート自体）に近いテーブル）のPTEは、次の下位レベルのテーブルがどこにあるか（存在する場合）を通知します。

RAMmapで示される数は、すべてのプロセスとOSのすべての常駐（RAM内）ページテーブルが占める物理メモリ（RAM）です。

ここで重要なのは、OQのシステムに2.5 GBのRAMがページテーブルと関連付けられていたことです。つまり、少なくとも2.5 GBのページテーブルが定義されています。ページテーブル自体がページング可能であるため、仮想サイズは物理サイズよりもはるかに大きくなる可能性があります。これはすべてのRAMmapで表示できます。しかし、それが「わずか」2.5 GBであると仮定します。PTEあたり8バイトで、約3億2000万PTEです。各PTEは1ページ（4Kバイト）の仮想アドレス空間を定義するため、 1.2 テラバイトを超える仮想アドレス空間がメモリ内ページテーブルによって定義されます。

それは不可能ではありませんが、かなり多くなります。

参考までに、私のシステムATMでは、ページテーブルに約125 MBのRAMがあります。これは、約65 GBの仮想アドレス空間のみを示します。実際の仮想使用量ははるかに多くなっていますが（プロセスのみで125 TB）、ほとんどのページテーブルがRAMにないためです。ここで説明すべきではないもう1つの「大きなページ」も、ページテーブルのサイズと使用中の仮想アドレススペースのサイズの比率の違いを明らかにするのに役立ちます。

そのため、原因を特定するために、まず「パフォーマンスバイト」カウンター値が高いプロセスのプロセスカテゴリの下にあるパフォーマンスモニターを調べます。

レノボ「RapidBootシールド」は私にとって犯人でした。

再起動せずに1週間後、「ページテーブル」は4GB以上を使用していました。RamMapの[Processes]タブに示されているように、終了したすべてのプロセスが20K RAM（4Kプライベート、16Kページテーブル）を使用してスタックし、約200,000があったことがわかりました。

再起動するとリストは減りましたが、再び増え始めました。メモ帳を開いて強制終了し、RamMapプロセスリストに残っていることを確認することで再現できました。

このtechnetスレッドの提案に基づいて、「RapidBoot Sheild」をアンインストールし、マシンを再起動すると、プロセスが強制終了されたときに残っていません。問題が解決しました！

私の場合、これらはAladdin Knowledge Systems AladdinドライバーのAksdf.sysおよびHardlock.sysフィルタードライバーでした。私もRAMMapを使用してその答えを見つけることができました。終了したプロセスによって消費されたメモリを表示しました。プロセスはWindowsプロセスリストから削除されましたが、メモリマップに残っています。ドライバーがプロセスの完全な終了を妨げているようです。

私はIT部門にこれについて尋ねました、そして彼らは同様に竹で覆われました。DriverEasyを使用してドライバーを更新しました。奇妙なことに、違いをもたらしたと思われるのはモニタードライバーでした。以前は、標準のWindows "Generic PnP Monitor"ドライバーがありました。しかし、それらをモニターの正しいメーカーとモデルに更新すると、問題は解消されたようです。

RamMapの[Processes]タブを開き、名前で並べ替えます。同じプロセスの疑わしいほど高い数を探します。私のマシンでは、「SynTPEnh.exe」が原因でした（タッチパッドドライバーの一部）。1週間の稼働時間の後、ページテーブルに32KBのエントリが数万個集まりました。

ページテーブルのサイズは1 GBでしたが、再起動後は50 MBしかありません。