ページファイルが使用されないのはなぜですか？
Windows Server 2008 R2Enterpriseに問題があります。ページプールはメモリをロードしますが、実際のページファイルをロードしません（ドライブにそのためのスペースがあります）。
実際、問題はメモリの過剰な負荷にあり、これが問題であると思いました。
仮想メモリ設定：
ページファイルの使いやすさ： 
そしてメモリ使用量はまだゆっくりゆっくりと増加します
タスクマネージャーのパフォーマンス： 
タスクマネージャーのプロセス： 
RAMマップ： 
システムインフォメーション： - 
最初のコメント：「カーネルメモリ-ページ」の表示は、ここではほぼ22 GBで、virtualサイズのpagedプールです。
Windowsの「プール」は、カーネル空間のヒープストレージです。これらは、ユーザーモードプログラムでヒープが使用されるのとほぼ同じ方法でカーネルドライバーとWindowsカーネルモードコードで使用されますが、すべてのプロセスに共通のカーネルアドレス空間にあり、もちろんカーネルモードからのみアクセスできます。プールの割り当てにはいくつかの種類がありますが、それらは「非ページ」領域と「ページ」領域に分類されます。非ページプールは常にRAMに常駐します。
ページングされたプールは、実際には「ページング可能な」プールと呼ばれる必要があります。「ページングされたプール」と呼ばれるからといって、isRAMからページアウトされたり、RAMからページアウトされたりするわけではないからです。必然的になります。これは、ほとんどのユーザーモードの割り当てと同じようにページアウトされる可能性があることを意味します。
また、ユーザーモードの割り当てと同様に、ページプールの仮想サイズのサブセットは、RAM（ページフォールトを発生させずにアクセス可能）で「常駐」または「有効」になるといつでも予想できます。 ;そのようなRAMは「使用中」と見なされます）;別のサブセットは「移行中」（スタンバイまたは変更されたページリスト上にあり、アクセス可能ですがソフトページフォールトがあります）になり、残りは「使用中」になります本当にページアウトされます-ページファイルで、アクセスするにはハードページフォールトが必要です。
現在、22GBはページプールのlotです。つまり、本当に、本当にたくさん。そのような量は非常に珍しいです。ふるいのようにページメモリをリークしているデバイスドライバに障害があると思われます。
PoolmonまたはWindowsPerformance Toolkitを使用して、そのすべてのプールに何が割り当てられているかを調べます。 SUには、これを詳細に行う方法を示す多くの回答があります。
あなたの質問へのコメントで、magicandre1981は手順を詳述する彼の答えの1つにリンクしました。
それを超えて、何かがページファイルへの書き込みを妨げているようです。
RAMmapからのスクリーンキャップ（およびそれを含めていただきありがとうございます）は、RAM（これは仮想サイズよりも小さいことに注意してください）、約620MBを占有している19GBのページプールのことを示していますその多くは「アクティブ」です。つまり、RAMは「使用中」と見なされます。これは、ページフォールトなしでアクセスできる部分です。これらの仮想ページを記述するPTEには、 「有効な」ビットが設定されています。
ほぼ同じ量、約680 MBが、スタンバイページリストにあります。
次に、2番目の問題の指標があります。17GBを超えるものが「変更済み」リストにあります。
「変更済み」ページリストは、ページが取り込まれてからコンテンツが変更された後、ワーキングセットから移動されたときにページが配置される場所です（ページがページインされてからページのコンテンツが変更されていない場合は、ワーキングセットから失われ、「使用可能」の一部であるスタンバイページリストに追加されるだけですRAMそしてすぐに他の用途に転用可能です。）このようなページは、他のプロセスで使用するために単純に解放することはできません。ページファイルでバックアップされたページの場合、「保存済み」は「ページファイルに書き込まれる」ことを意味します。
変更されたページがディスクに書き込まれると、スタンバイリストに移動され、そこから再利用できます。スタンバイリストは、「使用可能な」RAMの一部としてカウントされます。 （これは、そのタスクマネージャー表示の「キャッシュ」カウンターの一部でもあります。）
したがって、変更されたページリストに17GBを超えるRAMがあります-RAM）は、システムがページファイルに書き出すことを望んでいます。
これは非常に過剰です。
ほとんどのシステムでは、変更リストにRAMの数パーセントしかありません。システムプロセスには、変更されたページをディスクに書き戻すためのスレッドがあります。変更されたリストが小さなしきい値を超えています。彼らは仕事をしていません。
現在のページファイルのサイズは約5GBであり、WMI出力ごとにいっぱいになっています。 （つまり、システムはisページファイルに書き込んでいます。）しかし、何らかの理由で、ページファイルの拡張が行われていないようです。
うーん-ページファイルのサイズを最大20GBに制限しました。そのサイズに拡張したとしても、現在のコンテンツに17GBを加えたものを保持するには不十分です。おそらく、可能な最大PFサイズを大きくした場合（Windowsでは約40 GBが推奨されます）、問題が解決する可能性があります。
しかし、私はそれを疑っています。 Windowsがページファイルを制限まで展開しない理由はわかりません。確かに、変更されたページのすべてを保持するわけではありませんが、それらのほとんどを保持する方が、RAMに多くのページを保持するよりもはるかに優れています。
一方、これらの17 GB以上は、他の用途には「使用できません」。これが、「使用可能」RAMが非常に低い理由です。
ページファイルサイズのバグは、次の方法でクリアされます。
- ページファイルを無効に設定する
- シャットダウンして再起動します
- 古いページファイルがなくなっていることを確認してください。そうでない場合は、削除してください。
- ページファイルのサイズを適切なサイズに設定します
- 必要に応じて、シャットダウンして再起動します
あなたはそれを試すかもしれません。
しかし、あなたの本当の問題は、そもそも20GBのページプールを本当に必要とすべきではないということです。それを見つけて修正します。
その後、ページファイルの使用状況を再度確認し、初期サイズを通常の使用量の少なくとも2倍に設定する必要があります。システムが日常的に必要とするよりも小さい初期サイズを設定する正当な理由はありません。 （スペース割り当てアルゴリズムに関係している理由から、ページファイルの使用率が25％を超えないようにするのが好きです。多くの空き領域があると、ページファイルの動作が大幅に向上します。）
ところで、「スタンバイ」ページと「変更済み」ページの両方が、そのタスクマネージャー画面の「キャッシュ」の一部として（私の意見ではやや誤解を招くように）カウントされます。したがって、17.4 GBの「変更済み」があるという事実は、その膨大な「キャッシュ済み」数を説明しています。膨大な「キャッシュ」数自体は問題ではありません。それは症状の1つです。
ページプールは、カーネルモードコードの分類です。カーネルモードコードは、操作にページプールまたは非ページプールを使用し、特定の操作では特定のタイプが義務付けられます。これは、ページファイルによって裏付けられている場合とされていない場合があります。ページングを割り当てて使用するのはオペレーティングシステム次第です。実際、ページングにはI/Oのコストがかかるため、OSは可能な限り物理的に保持することを好みます。私が見るように、x64ビットOSの24GB物理は構成です。 OSは、プライマリメモリ内のほとんどの操作を非常にうまく管理できます。
https://technet.Microsoft.com/en-us/library/ff382715.aspx
上記のリファレンスは、キャッシュされたサイズについて理解するのに役立ちます。
これは問題ではないと思います。また、あなたが使用したツールの明らかなメトリックが表示されるものを超えて詳しく説明することはおそらくできません。
編集：-すべての分析「〜40のコメントを参照」の後、犯人はサードパーティのドライバーであることが判明しました。これが確かに問題であるという一流の分析/表示（クレジット：Jamie Hanrahan）とページプール分析（クレジット：Magicandre）の助けを借りて行われた分析。実際の質問に答えるには、さらに分析が必要です。