ページファイルサイズの最適化: ピークコミットと物理 RAM について詳しく教えてください。

Question

間違いなくあなたが言及しているのは「Windows の限界に挑戦: 仮想メモリ」マーク・ラッシノビッチ著。

はい、その番号です。
はい、使用可能な RAM は 2.5 GB のみです (おおよその値です。ここでは過剰な精度は必要ありません)。

しかし、あなたは「正しく行う」と書いています。マークの記事は「限界を押し上げる」ことについてであり、その公式は絶対最低限ページファイルサイズについて。システムのパフォーマンスを向上させたい場合は、「限界を超える」ことは避けてください。

その記事には、すべき設定をそのくらい小さくしてください。本当に必要な場合にのみ、この設定で済みます。(コミットされたメモリが実際にそれ以上必要にならないと仮定します。)

(そして、もっと必要になるかもしれません。ここで見たこの「ピーク」は、Process Explorer の実行期間中のピークにすぎないことに注意してください。その期間中に最大のアプリワークロードを実行した場合にのみ意味があります。これは、一度に実行すると思われるすべてのアプリを起動することを意味するだけではありません。各アプリに、要求する最大のプライベートメモリ (「コミット」メモリ) を使用させる必要もあります。これは、セットアップとテストが難しいことです。また、通常のワークロードに別のアプリを追加しないとは誰が言えますか? したがって、監視ツールで取得した情報には、絶対にそれ以上のメモリが必要にならないという保証はありません。)

実際にそのピークに再び達し、ページファイルをそのように計算した最小値に設定した場合、exe や dll などのコードファイルなどのマップされたファイルによって使用される RAM 用のスペースが RAM になくなることに注意してください。(これは、「コミットされた」仮想メモリの数にコードページやマップされたファイルによってバックアップされたその他のページが含まれていないためです。) コードを実行するには RAM 内になければならないため、これは問題です。

はい、ページファイルの拡張を有効にしているので、これは「致命的な」問題ではありません。ただし、パフォーマンスは確実に低下します。

したがって、パフォーマンスの問題に関係なく、アプリがクラッシュしない絶対最小のページファイルサイズを何らかの学術的な理由で実証しようとしているのでない限り、そのようにはしません (そうする実用的な理由は思いつきません)。

本当に物事を実用的最小値、つまりコードに使用できる RAM を制限せずに、ページファイルの最小サイズを観測された最大コミットチャージに設定するだけです。つまり、アプリと OS がその量のコミットメモリを作成して (すべて参照して) いても、コードに使用できる RAM が残ります。

また、ディスク使用量を非常に気にしない限り、最大サイズを最小サイズの 2 倍に制限する理由もありません。

ご存知のとおり、システムが必要とするサイズよりも大きいページファイルを持つことは、ディスク領域の使用量以外には害はありません。特に、必要以上に大きいページファイルは、それ以上のページングを「引き付ける」ことはありません。また、ぎりぎり十分な大きさにすることには、（ディスク領域の使用量以外に）利点はありません。では、なぜわざわざそうするのでしょうか。つまり、この作業で占有されるディスク領域以外、何も「最適化」していないのです。

コミット制限を超えるとアプリがクラッシュする可能性があり (したがってデータが失われる)、まれにシステムがクラッシュすることもあるため、ページファイルをできるだけ小さくすることにはあまり関心がありません。

一方、システムがページファイルに頻繁に書き込む必要がある場合 (使用可能な RAM が 2.5 GB しかない Windows 7 システムではそうなると思います)、システムが使用するよりもかなり大きいページファイルがあると、処理速度が向上します。なぜでしょうか。空き領域がたくさんあると、ページファイルに使用される領域割り当てアルゴリズムが大幅に高速化されるからです。

このため、Pagefile %usage の PerfMon カウンターが 25 パーセント未満に留まるようにしたいのです。

Answer 1