そうであれば、発生したオーバーヘッド (ジャーナリングなど) をどのように正当化しますか? そうでない場合、ページファイルが断片化されるのはなぜですか? さらに、クラスタ サイズを大きくするとページ ファイルのパフォーマンスが向上しますか (クラスタのスラック スペースは問題ではありません)。
2 に答える
システムは、必要に応じて、ファイルシステムコールを使用してページファイルにアクセスします。ジャーナリングなどのオーバーヘッドは基本的にゼロです。ジャーナリングは、ファイルシステム構造が変更された場合にのみ有効になり、個々の読み取りまたは書き込みには有効になりません。デフォルトでは、XPは初期サイズが物理メモリのサイズの1.5倍に設定された半固定ページファイルを使用します。通常の状態では、ページファイルがこれより小さくなることはありません。このサイズが適切であり、適切なRAMサイズがあれば、ほとんどの場合これが当てはまり、ページファイルのサイズが変更されることはありません。このまれなイベントでのみ、新しいクラスターがページファイルに割り当てられ、断片化の可能性があります。再起動時、またはそれより早く、ページファイルのすべての拡張機能が解放され、初期サイズに戻ります。通常の状態では、断片化は発生しません。
ページファイルは、めったに使用されないデータを保持するために、多かれ少なかれ継続的に使用されます。これらの書き込みは、CPUとディスクへのアクセスが非常に少ない時間帯に行われるため、パフォーマンスに影響を与えません。関連するデータが使用されることはめったにないため、ページファイルへのアクセスがパフォーマンスに深刻な影響を与えることはめったにありません。ページファイルは、メモリが不足したときに使用される単なるオーバーフロー領域ではありません。ほとんどの場合、ページファイルは、静的データを長期間処理する必要からRAMを解放することにより、パフォーマンスを向上させます。
filemon または procmon (sysinternals.com) を参照して、OS がページファイルに書き込みを行っていることを確認できます。そのため、適切なファイルシステム セマンティクスを使用する必要があります。
メモリ不足のためにスワッピングを行っている場合は、既にパフォーマンスの戦いに負けており、オーバーヘッドが損失に大きく追加されることはありません (ただし、ファイルシステムが破損していないことを意味します)。スワッピングがパフォーマンスに重要でない場合、ジャーナリングのわずかなパフォーマンス ヒットを誰が気にしますか?
クラスターのサイズは、インデックスからディスク上のストレージにマップされるだけなので、問題になることはほとんどありません。ページファイルのサイズが変更されることはめったにないため、インデックスはほとんど変更されません。