そして、なぜその量の 2 倍を最大にしたいのでしょうか。私のシステムには 32 GB の RAM があり、Windows はデフォルトで、最小 16 MB の仮想メモリを設定し、32 GB(!) を割り当て、50 GB(!!) を推奨します。64 GB RAM システムではさらに悪く、100 GB 以上を割り当てることを推奨しましたが、RAM で使用可能な量と同じ量 (この場合は 64 GB) が「のみ」使用されました。
私が理解している限り、ページファイルの概念は、Windows が必要に応じてのみページファイルを拡張し、最初は最小量で開始し、実際にはそうならないものの、常に絶対最大値まで拡張するというものです。これは非常に厄介な問題です。ページファイルを無効にしたり、インストールされている RAM と同じ量に設定しなかったりすると、7zip などの大量のメモリを使用する一部のプログラムで問題が発生し、使用可能な空きメモリが十分にあるにもかかわらず、割り当てるメモリが足りないと表示されるからです。
この動作により、ドライブ (SSD) の寿命が大幅に短くなる可能性があります。Windows がこのような動作をするのはなぜですか。また、これを防ぐにはどうすればよいですか。あるいは、一部のプログラムで異常な動作を起こさずにページファイルを完全に無効にするにはどうすればよいですか。
答え1
まず、ページファイルのサイズを設定する Windows のダイアログで、ページファイルが「仮想メモリ」とみなされていることは大きな間違いです (これはあなたの間違いではありません)。ページファイルは、プライベートコミットメモリによって使用される仮想アドレス空間の 1 つのカテゴリのバックアップストアにすぎません。他のファイル (マップされたファイル) によってバックアップされる仮想アドレス空間と、常にページング不可能で常に RAM に保持される仮想アドレス空間があります。しかし、少なくとも仮想アドレスから RAM アドレスへの変換が常に機能しているという点で、これらはすべて「仮想メモリ」です。
あなたの観察は正しいです。Windows のページファイル サイズの割り当ては、デフォルト = RAM サイズ、最大 = その 2 倍という単純な計算を使用します (以前は 1.5 倍と 3 倍でした)。何らかの値に設定する必要があり、これらの要素によってほぼ常に十分な結果が得られます。また、システムがクラッシュした場合にメモリ ダンプをキャッチするのに十分なページファイル領域も保証されます (カーネル ダンプまたはフル ダンプを有効にしていると仮定)。
私が理解している限りでは、ページファイルの概念は、Windows は必要なときにのみページファイルを拡張し、最初は最小量で開始しますが、実際にはそうはなりませんが、常に最大量まで拡張されます。
ああ...「初期サイズ」から始まります。これは「許容される最小サイズ」ではありません。Windows は初期サイズとして RAM サイズを使用するため、RAM サイズで表示されるのはそのためです。
しかし...実際のページファイル サイズが最大設定になっていると言っているのですか? たとえば、初期サイズが 16 GB、最大サイズが 32 GB に設定されている場合、実際のサイズ (「現在割り当てられている」サイズ) は 32 GB になっているのですか? ちなみに、再起動すると常に初期サイズに戻るはずです。
「システムの仮想メモリが不足しています」というポップアップが表示されましたか? OS がページファイルを現在のサイズを超えて拡張すると、表示されるはずです。
OS は、何かが実際に大量のプライベート コミット メモリを割り当てようとし、そのメモリを格納するために拡大されたページファイル スペースが必要になった場合を除いて、ページファイルを拡大することはありません。しかし、何かがそうした可能性があります。タスク マネージャーのプロセス タブを見てください。[コミット サイズ] 列に、各プロセスについてこの値が表示されます。列の見出しをクリックすると、誰がメモリを消費しているかがわかります。:)
これは非常に迷惑なことです。ページファイルを無効にしたり、インストールされている RAM と同じ量に設定しなかったりすると、7zip のように大量のメモリを使用する一部のプログラムで問題が発生し、使用可能な空きメモリが十分にあるにもかかわらず、割り当てるメモリが足りないと表示されるからです。
これは、使用可能な RAM ではなく、「コミット チャージ」と「コミット リミット」と呼ばれるものに関係しています。「コミット リミット」は、(RAM - ページング不可能な仮想メモリ) + 現在のページ ファイル サイズの合計です。(空き RAM ではなく、RAM のみです。) したがって、たとえば 8 GB の RAM と 16 GB の現在のページ ファイルを持つシステムの場合、コミット リミットは約 24 GB になります (「約」というのは、ページング不可能なコンテンツを保持する RAM はコミット リミットにカウントされないためです)。
「コミット チャージ」とは、現在システム内に存在するプライベート アドレス空間の量です。これはコミット制限より小さくなければなりません。そうでないと、システムは、その内容が保存される場所があることを保証できません。
タスク マネージャーの [パフォーマンス] タブでは、凡例「コミット (GB)」とともにこれらの 2 つの数値を確認できます。たとえば、「コミット (GB) 1/15」と表示されているマシンを確認しています。これは、15 GB の制限のうち、現在のコミット チャージが 1 GB であることを意味します。
7zip のようなプログラムが、たとえば (commitLimit - commitCharge) より大きいサイズの VirtualAlloc、つまり「残りの」コミット制限より大きいサイズの VirtualAlloc を実行しようとすると、OS がページファイルを拡張してコミット制限を十分に大きくすることができなければ、割り当て要求は失敗します。これが、発生している現象です。(Windows には、実際には「物理メモリが不足しています」というエラー メッセージはなく、ユーザー モード アクセスに対してもエラー メッセージはありません。仮想に対してのみエラー メッセージがあります。)
それは何の関係もありません無料RAM は、すべての RAM (ページング不可能な小さなビットを除く) が、現在空いているかどうかに関係なく、コミット制限にカウントされます。
こうした割り当て失敗の 1 つが発生した後にシステムを確認すると、明らかに問題は何も見当たらないため、混乱を招きます。システムを確認すると、コミット チャージは制限をはるかに下回っており、空き RAM もたくさんある可能性があります。問題の原因を確認するには、プログラムが割り当てようとしていたプライベート コミット メモリの量を知る必要があります。ほとんどのプログラムは、そのことを教えてくれません。
7zip は vas の割り当てに非常に積極的すぎるように思えます。RAM サイズに基づいて要求をスケーリングしているのかもしれません。7zip が満足できるより小さなページファイル設定はないのでしょうか。7-zip の 32 ビット版と 64 ビット版のどちらを使用していますか。32 ビット版を使用すれば、2 GB または 3 GB を超える仮想アドレス空間を使用することはできないため、この問題が解決されます。もちろん、巨大なデータセットではそれほど高速ではない可能性があります。
この動作により、ドライブ (SSD) の寿命が大幅に短くなる可能性があります。
いや、実際はそうではありません。ページファイルを任意のサイズで単に配置するだけでは、システムが実際にそのページファイルにその量を書き込むことにはなりません。(「シャットダウン時にページファイルをクリアする」オプションが設定されていない限り、その場合でも、すべてを書き込むことはないと思います。Mm はどのブロックが使用されているかを認識しており、それらのブロックのみを書き込むはずです... これまでそのことについて考えたことがありませんでした。確認する必要があります。)
ページファイルに実際にどのくらいの量が含まれているかを確認したい場合は、PerfMon ユーティリティを使用します。ページファイル用のカウンター グループがあり、当然「% 使用率」カウンターが必要になります。このパーセンテージは、ファイルの実際のサイズ (エクスプローラーに表示されるサイズ) に基づいて解釈します。
これはかなりのスペースを消費します。SSD のスペースはかなり高価なので、ほとんどの人にとっては懸念事項です。試すことができる方法の 1 つは、SSD に 4 GB または 8 GB などの適切なサイズのページファイルを配置し、次に回転するドライブを接続して、その上に大きなページファイルを配置することです。または、ページファイル用に SSD のみが必要な場合は、2 番目のページファイル専用に安価で小型の SSD を購入してください。