これはWindowsに関するものですが、他のOSにも当てはまると思います。
パフォーマンスを向上させたい場合は、スワップファイルの断片化を避けるべきだと人々が言うのを聞いたことがあります。これを行うには、スワップファイルに一定のサイズを手動で指定するか、専用のパーティション/ディスクに移動することもできます。
これは本当にパフォーマンス上の利点をもたらしますか?結局のところ、スワップファイルはとにかくランダム化された方法でアクセスされますが、もう少しランダム化とは何ですか?また、スワップファイル用に別のディスクを検討している場合は、代わりにもっと多くのRAMに投資するほうがはるかに良いでしょう。もちろん、空きディスクを入手しない限り。
それで、スワップファイルの断片化と戦うことに意味はありますか?
ページファイルの断片化は、極端な場合にのみ重要な要素になります。大きなファイルが連続して読み取られる場合、断片化は要因ですが、これはページファイルではほとんど発生しません。ページファイルへのアクセスは64K以下の小さなブロックで行われ、これは通常、他のファイルへのアクセスと混合されます。ページファイルが断片化されているかどうかはほとんど問題ではなく、ディスクヘッドはどのような場合でも動き回っています。
ページファイルのパフォーマンスが制限要因でない限り、これは実際には重要ではありません。そして、それは通常そうではありません。ほとんどのページングはページファイルをまったく使用しません。設計上、ページファイルは、頻繁にアクセスされないデータを格納するために使用されます。ほとんどの場合、ページファイルは、パフォーマンスが重要になるほど頻繁にはアクセスされません。
ほとんどの場合、これはほとんど何もありません。問題を解決するための誤った試みは、深刻な問題を引き起こす可能性があり、しばしばそうします。
これは、スワップが常にスワップファイル用の特別なファイルシステムを備えたパーティションであるLinuxシステムでは確かに問題ではありません。これは明らかにWindowsで発生する可能性のある問題であり、スワップにファイルを使用しているように見えるため、Mac OSXでも発生する可能性があると思います。
TBH、私の見解を裏付ける確かな事実はありませんが、スワップサイズを変更するとウィンドウが遅くなるように見えるため、スワップのサイズを変更しない方がよいことを示唆する事例証拠があります。スワップに必要なディスクのサイズは、現在平均的なディスクと見なされているサイズよりも常に小さいため、通常、古いディスクはスワップに十分な大きさです。したがって、最新の1TBディスクにアップグレードする場合は、古いディスクに適している可能性があります。
Windowsマシンを実行するときは、常にスワップパーティションを作成するか、別のディスクを使用し、そのディスクのみをスワップに使用し、サイズを変更しないように設定するようにWindowsに指示しました。 RAMの量の2.5倍を最小値と最大値の両方として使用するように設定し、そのままにしておきます。それが本当に役に立ったかどうかを確実に知る方法はありませんが、確かにマイナスの副作用はありませんでした。
要するに: はい
スワップファイルの断片化は実際の問題であり、ハードドライブの空き容量が少ないほど発生する可能性が高くなります。レジストリdbファイルのように発生する可能性のある他のファイルもあります。 Microsoftは、Windowsにスワップファイルのサイズを制御させることについてのアドバイスを非常に明確にしており、手動で行うことは悪いと見なされており、ごくわずかな場合にのみ行う必要があります。この問題には、 systeminternals 呼び出された pagedefrag からの簡単な解決策があり、システムの再起動時にロックされたファイル(ページングファイルを含む)をデフラグできます。また、これらのファイルの現在のステータスも表示されます。
また、ファイルの断片化は回転するハードドライブの問題にすぎないことにも注意してください。ファイルがSSDで断片化されている場合、パフォーマンスの問題ではないことを理解しています(SSDのデフレイジャーはファイルの寿命を短くするだけです)。実際のパフォーマンスの低下は、その断片化とシステムハードウェアの程度(ハードドライブでのシーク時間とシステムがページファイルにアクセスする頻度)に大きく依存しますが、この問題を簡単に取り除くことができることを考えると、問題はないはずです。 。
リンク: [〜#〜] msdn [〜#〜] on pagefile Mark Talking about Virtual memory (Pagefile)
ここで実際に観察可能なパフォーマンスの低下を防ぐには、HDをひどく断片化する必要がありますが、それでも理論は正しいです。理由は、(明らかな理由で)スワップファイルを最速のディスクに置き、シーク時間があまり発生しないように、すべてを連続した物理的な場所に保持することです。サーバーや愛好家のワークステーションにとって、これは完全に理にかなっています。シングルディスク/シングルパーティション設定の一般的なオフィスPCの場合、「最速ディスク」オプションはなく、ヘッドが実際のファイルとスワップファイルの間を移動するときに常にシーク時間が発生するため、そこに神話。
内部と外部の断片化を区別する必要があります。
各プロセスのサイズが異なるため、スワッピング(つまり、プロセス全体をディスクに配置する)を実行すると、外部の断片化が発生します。 LinuxもWindowsも実際にはスワッピングを実行しませんが、ページング(固定サイズのメモリフレームをディスクに配置する)を実行するため、外部の断片化の問題は実際にはありません。
各フレームのサイズは同じですが、すべてのページがいっぱいであるとは限らないため、ページングを実行すると内部フラグメンテーションが発生します。一部のページは制限まで使用されません(=内部フラグメンテーション)。この問題は、ページングを使用するときに常に存在します。
しかし、私はあなたがページフレームを保持するファイルシステム(ファイルシステムのブロックが完全に使用されていない)の内部断片化の発生を意味すると思います。これは、ファイルシステムのブロックサイズをページフレームのサイズと等しくなるように選択することで回避できます。
スワップファイルを別の物理ディスクに置くと、スワップするときにデータディスクからIOを実行しているため、パフォーマンスが向上することを知っています。両方の操作のパフォーマンス。つまり、これがあらゆる面で最良のオプションです。
「空きディスク」については、どうしますかthinkオフィスの周りにある古い8 GBのハードドライブをすべて使用しますか? ;)それ以外の場合は、RAMは(デスクトップの場合)最近はとにかく安価であり、可能な限り最良のオプションです。
いいえ、時間、お金、労力を必要としない限り、スワップファイルの断片化と戦う意味はありません。
私はいくつかの長く曲がりくねったアナロジーを思いついたが、気が変わっていない限り、あなたを惜しまないことに決めた:)
スワップファイルの断片化は実際に発生しますが、実際の生活では、デフラグツール会社が信じているほど大きな違いはないと思います。
私はよくウィンドウにスワップファイルを別のドライブに作成するように指示しましたが、それはデフラグされたばかりで(新しいファイルが作成されます)、日々の操作の違いに気づいたとは言えません。
「ユーザーはただ」いくつかのアプリケーションを閉じる必要があることを認識したレスポンダーの場合:Bzzzzzt !!どんな文脈でも間違った答え。
マシンに「十分な」RAMがあれば、スワップファイルが不足しているかどうかにかかわらずRAM断片化、モノリシック、脱カフェイン、または漂白。
スワップファイルを処理できるデフラグツールに費やしたお金は、RAMに費やしたほうがよいでしょう。マシンを256MBのRAMから2GBにアップグレードすると、スワップファイルがどれほど無関係になるかは驚くべきことです。