SSDでページファイルを無効にする必要がありますか？
私は読んでいます この質問 、そしてそれはたくさんの素晴らしい情報を持っています。
しかし、十分なRAMがある場合は、SSDでページファイルを無効にして寿命を延ばす必要があると思います。クラッシュでコアダンプが失われることはわかっていますが、その情報を必要とする人は多くありません。
私の理解では、ページファイルがないと、RAMの制限に達すると、ディスクでスラッシングが発生する可能性があります。しかしSSDの場合、スラッシングの概念はなく、読み取りは高速です。
皆さんはどう思いますか？
しかし、十分なRAMがある場合、SSDではページファイルを無効にして、寿命を延ばす必要があると思います。クラッシュするとコアダンプが失われることは承知していますが、その情報を必要とする人は多くありません
これは、時期尚早の最適化のように聞こえます。使用するSSDについてはまだ説明していません。また、サーバーのワークロードと計画しているSSDデータシートを実際に確認しないと、ページファイルがSSDの寿命にどのような影響を与えるかを理解することはできません。
優れたインターネットとここのサーバー障害の両方で、SSDの寿命が短いという誤った情報が大量にあります。初期のモデルのSSDには問題があった可能性があり、USBフラッシュドライブは確実に劣化し始めますが、エンタープライズクラスのSSDには、はるかに優れたウェアレベリングアルゴリズムがあり、スペアフラッシュを使用してパフォーマンスと摩耗を改善するものもあります。
Intel X25-Eドライブ たとえば、32 GBドライブに対して1ペタバイトのランダム書き込みの書き込み期間を要求します。書き込みインターフェース（200 MB /秒）を無停止で、上書きで飽和させている場合、私の見積もりでは約58日間続くと推定されます。ただし、そのドライブには1日あたり17 TBのデータが書き込まれます。
ページファイルがある場合でも、OSドライブの一般的なサーバーワークロードははるかに少なくなります。 1日あたり50 GBと呼びます。 1 PBの数値が正確である場合（そして、平均値と見なされる可能性があることはわかっていますが、後で詳しく説明します）、それはまだ50年の北のどこかです。
もちろん、これらの数値は途方もなく高いように見えるので、 予想されるドライブの寿命のためにインテルが引用した実際の数値 を見てみましょう。 Intelは、MLC（非エンタープライズ）ドライブを5年間、毎日100 GBのデータを書き込むように認定しました。 SLCとMLCフラッシュの標準的な理解では、SLCフラッシュの持続時間はMLCの約10倍です（上記のリンクはこれもグラフで示しています）。
もちろん、真実は時間までに明らかになるでしょう-ドライブが早く故障するのを見始めるか、そうしないかです。しかし、ドライブの背後にある数を合計すると、ドライブの寿命はまともな品質のSSDの問題ではない。
MLC SSDを使用している場合、おそらく心配することは正しいでしょう。ただし、インテルが5年間100 GB /日でドライブを評価しても問題ない場合でも、基本的には10年間50 GB /日と同じです。そして、元のポイントに戻ると、ドライブで実行する実際のワークロードの種類を知る必要があります。
個人的には、運用サーバー環境ではMLC SSDを使用しないことを強くお勧めします。まともなSLC SSDが高すぎる場合は、今のところディスクの回転に固執します。
（余談ですが、「SLCはMLCよりも10倍長持ちする」という評価である50年間、1日あたり100 GBの数値を使用すると、Intelは実際に32 GBドライブの総書き込み寿命があると言っているようです製品仕様に引用されている1 PBではなく、2 PBのデータに近い値です。これらの2つの値のうち小さい方だけが信頼できるとしても、私のX25-Eドライブは10年よりかなり長く続くはずです。）
Daniel Lawsonが言及しているように、おそらく問題ではない長寿に加えて、MSチーム自体からのフィードバック（下記）に加えて、
- とにかく必要な場合にのみページファイルが使用されます
- ページファイルが使用されている場合、SSDにページファイルがあると、回転するハードドライブに大きな違いが生じます。
ページファイルはSSDに配置する必要がありますか？
はい。ほとんどのページファイル操作は、小さなランダム読み取りまたは大きな順次書き込みであり、どちらもSSDが適切に処理できるタイプの操作です。
何千ものトレースからテレメトリデータを確認し、ページファイルの読み取りと書き込みに焦点を当てると、
- Pagefile.sysの読み取り数pagefile.sysの書き込み数が約40対1
- Pagefile.sysの読み取りサイズは通常非常に小さく、67％が4 KB以下、88％が16 KB未満です。
- Pagefile.sysの書き込みは比較的大きく、62％が128 KB以上、45％がちょうど1 MBのサイズです。実際、SSDがそれらのパターンに対して持っている典型的なページファイル参照パターンと好ましいパフォーマンス特性を考えるとSSDに配置するためのページファイルよりも優れたファイルはほとんどありません。
ページファイルを完全に無効にするのではなく、使用しないようにOSに指示すると便利な場合があります（たとえば、sysctl vm.swappiness=0）。
OSは、必要がない限りそれを使用しないようにし、SSDの不要な書き込みを保存します。
ページファイルは常に有効にしたままにします。 OSまたはアプリの特定の部分がexpect 1に書き込まれる可能性があり、存在しない場合は正しく動作しない可能性があります。
そうは言っても、私は過去にページファイルなしでWindows（XP）を実行したことがあり、私が投げたすべてのものに完全に満足しています。気に入らない何かがやって来るとはいえ、常に微妙な疑問がありました。
オプションはそれを本当に小さく設定することかもしれません。
これはOPに直接反応しませんが、ロナルドとダニエルによる上記の回答/コメントの誤った印象を修正したいと思いました。 （私は新しいので、コメントするのに十分なポイントがありません。）
[〜＃〜] trim [〜＃〜] は、実際にはbiggestの寿命を延ばすためにできることですSSD。理由は次のとおりです。SSDは定期的に「ガベージコレクション」を行います-部分的に空の消去ブロックから（断片化された）データをコピーし、新しく消去されたブロックに連続して書き込みます。
ホストがこれを認識する必要がないように、アドレスは再マッピングされます。ホストの書き込みに直接関連しないこの追加の書き込みアクティビティは、「書き込み増幅」と呼ばれます。 SSDが完全にフルであり、少量のオーバープロビジョニングされた（隠されたスペア）スペースがある最悪の場合、書き込みの増幅は、ホストの書き込み速度の500％から700％の範囲になる可能性があります。
SSDは、ガベージコレクション中に、無効化（上書きまたはTRIMmed）されたページをコピーして再書き込みする手間を省き、潜在的に大量の作業と書き込みアクティビティを節約します。ファイルシステムが大きなファイルを消去しても、TRIMを介してドライブに通知しない場合、ドライブは消去されたデータをコピーし続け、無期限に書き込みを浪費します（または、それらのブロックアドレスが他のファイルに割り当てられるまで、長い時間がかかる可能性があります）。
要約すると、TRIMは本当に寿命とパフォーマンスの両方にとって重要です。
仮想メモリ用に2台目のハードドライブを使用するだけです。
あなたがリンクした他の投稿でこれを述べましたが、私たちはページファイルなしで非常にメインラインのサーバーを実行しており、ここですべてがうまくいくようです。実際、それなしではより高速に見えます。 8 GBのRAMがあります。ハードドライブがSSDであるかどうかではなく、RAMが多いかどうかに基づいて判断する必要があると思います。不要な書き込みを行わないことで、その寿命を節約します。
8 GBのRAM、SSDシングルドライブ、ページファイルのないラップトップを1年以上使用していますが、問題はありません。私はページファイルを必要とする1つのゲームに遭遇し、ソフトウェアのWebサイトにアクセスして、それを無効にするrunコマンドを取得し、問題を解決しました。
私のラップトップは4年です。古いですが、一部の新しいデスクトップよりも高速に動作します。 SWAPファイルとも呼ばれるメモリリークは、手法の作成以来、Windows OSで問題となっています。残念ながら、Linux開発者はその足跡をたどっています。バックグラウンドで実行しているソフトウェアが少ないほど、優れています（特にMicrosoftの場合）。