SSDでのNTFS圧縮-アップとダウン

このトピックでは、ディスクアクセスのパフォーマンスを向上させる方法としてHDDでのNTFS圧縮について説明し、それが不十分であることが多いと結論付けています。しかし、私は常に圧縮をスペースを節約する方法と見なし、その効果を学びました。そして今、私はSSDを使用していますが、スペースが高価であり、たとえば1つではなく2つのクラスターの読み取り/書き込みのパフォーマンスが大幅に低下します。

一方、SSDはHDDよりもはるかに高速であるため、スループットが高くなるとCPU使用率も高くなると思います。これは問題になりますか？問題について他に何か考えはありますか？

スペース節約効果が好きです。それほど大きくはありませんが、そこにあります。ただし、パフォーマンスが気になる場合は、オフにします。

マイクロソフトはこれをブログで少し前に書いた。

NTFSは、データストリームをCUに分割することでファイルを圧縮します（これは、スパースファイルが機能する方法に似ています）。ストリームのコンテンツが作成または変更されると、データストリーム内の各CUは個別に圧縮されます。圧縮の結果、1つまたは複数のクラスターが減少した場合、圧縮されたユニットは圧縮形式でディスクに書き込まれます。次に、（以下の例に示すように）整列を目的として、疎なVCN範囲が圧縮されたVCN範囲の最後に追加されます。データが十分に圧縮されておらず、サイズが1クラスターだけ削減されない場合、CU全体が圧縮されていない形式でディスクに書き込まれます。

この設計では、ファイル内の単一のVCNにアクセスするために1つのCUのみを解凍する必要があるため、ランダムアクセスが非常に高速になります。残念ながら、シーケンシャル操作（バックアップなど）を実行するには多くのCUの解凍が必要なため、大規模なシーケンシャルアクセスは比較的遅くなります。

そしてKB記事でこれを書いています：

NTFSファイルシステムの圧縮はディスク領域を節約できますが、データの圧縮はパフォーマンスに悪影響を与える可能性があります。NTFS圧縮には、次のパフォーマンス特性があります。圧縮されたNTFSファイルを別のフォルダにコピーまたは移動すると、NTFSはファイルを解凍し、ファイルを新しい場所にコピーまたは移動してから、ファイルを再圧縮します。この現象は、ファイルが同じコンピューター上のフォルダー間でコピーまたは移動された場合でも発生します。圧縮ファイルはネットワーク経由でコピーする前に展開されるため、NTFS圧縮ではネットワーク帯域幅を節約できません。

NTFS圧縮はプロセッサを集中的に使用するため、パフォーマンスコストは、プロセッサに頻繁にバインドされるサーバーでより顕著になります。大量の書き込みトラフィックがある負荷の高いサーバーは、データ圧縮には適していません。ただし、読み取り専用、ほとんど読み取り、または負荷の軽いサーバーでは、パフォーマンスが大幅に低下することはありません。

トランザクションログを使用し、データベースまたはログに常に書き込むプログラムを実行する場合は、圧縮されていないボリュームにファイルを保存するようにプログラムを構成します。プログラムが圧縮ファイルのマップされたセクションを介してデータを変更する場合、プログラムはマップされたライターが書き込むよりも速く「ダーティ」ページを生成できます。この問題のため、Microsoftメッセージキュー（MSMQとも呼ばれます）などのプログラムはNTFS圧縮では機能しません。

ユーザーのホームフォルダーとローミングプロファイルは多くの読み取りおよび書き込み操作を使用するため、ユーザーのホームフォルダーとローミングプロファイルは、親フォルダーまたはボリュームルートにNTFS圧縮されていないボリュームに配置することをお勧めします。

概要：

読み取りは高速であるため、変更されない小さなファイルのみを読み取ります（読み取りのみで、書き込みは行いません）。ただし、書き込みには、非圧縮と、CPUパワーを必要とする新しい圧縮が必要であり、ストレージタイプはそれほど重要ではありません。

クラウディオが多くのことを詳細に言っているので、私も彼の意見を再開します。彼が言ったことを試した後、私は同じ効果を見ました。

SSDの場合、NTFS圧縮を使用しないでください。

今、私はそのような肯定のためのいくつかの動機を列挙します：

動機Nº1：2つの書き込みを行うため、SSDムッシュをより速く殺します。NTFS圧縮では、RAMで圧縮を開始する前に常に非圧縮データが書き込まれ、少なくとも4KiBのゲインがある場合にのみ圧縮データが再書き込みされます。

動機付けのN：2：SSDでNTFS 4KiBクラスターを使用すると、SSD速度の50％が失われます。ベンチマークを確認すると、128KiBブロックによってSSDが4KiBブロックを使用する場合より2倍高速になり、NTFS圧縮は4KiBクラスターのNTFSパーティションでのみ使用できます。

動機Nº3：オンザフライで圧縮または暗号化、あるいはその両方と見なされるコンテナーを作成できるコンテナー（PISMOファイルマウントなど）があり、そのようなコンテナーはRAMで圧縮を行い、再書き込みの前に非圧縮データをディスクに送信しません。また、圧縮形式では、PISMOの圧縮率はNTFSよりも優れています。

より多くの動機がありますが、それが最も重要なことです。

otrerポイントはSPEEDであり、すべての圧縮はCPUで行われるため、非常に高速なCPUがない場合（マルチスレッドが一部のコンテナで使用されているときに、NTFSではモノスレッドが使用されます）の読み取り/書き込みは非常に遅くなります。圧縮されたとき; 最悪の場合、非常に高速なCPUを使用できますが、それが他の用途（レンダリング、トランスコーディングなど）で使用されている場合、圧縮用のCPUが残っていないため、パフォーマンスが低下します。

NTFS圧縮は、CPUがあまり使用されていない従来の低速ディスクにのみ適していますが、各64​​KiBブロック（圧縮されているかどうかにかかわらず）が64KiBの倍数の位置に書き込まれるため、各書き込み（ファイルレベル）後に適切なデフラグが必要です。このようなフラグメントをパックする唯一の方法は、圧縮（または圧縮フォルダーに書き込む）後にそのようなファイルのデフラグを実行することです。

PD：仮想マシン内ではなく、実際のハードウェア上のWindowsについて話していることに注意してください。重要なのは、物理メディアへの書き込みを行う人です。他の人には、影響を軽減し、大幅に改善できるキャッシュレイヤーがある場合があります。

SSD以外での市長の問題について誰も話しません。それは断片化です。

各64KiBブロックは圧縮なしで書き込まれますが、圧縮可能であるため、少なくとも<= 60KiBである場合、64KiB未満で書き込み、ビットネストブロックは、前のブロックがなかったかのように移動します圧縮するため、多くのギャップが発生します。

任意のWindowsシステムのvirtuslマシンのマルチギガバイトファイルでテストします（50％に削減される傾向がありますが、10000を超える巨大なフラグメントがあります）。

そして、SSDについては言われていないことがあるのですが、一体どうやって書くのですか？つまり、圧縮されていない状態で書き込み、圧縮されたバージョン（64KiBメガブロックごと）で上書きすると、SSDの寿命が大幅に短縮されます。圧縮形式で直接書き込む場合、SSDライブは長くなるか短くなる可能性があります... 64KiBを一度に書き込む場合は長く、64KiBを4KiBで書き込む場合は長くなるため、このような64KiB（圧縮形式）は、64/4 = 16倍です。

パフォーマンスの低下は、圧縮/圧縮解除に必要なCPU時間が、4KiBブロックを書き込む必要がない場合に得られる時間よりも大きいために発生します...したがって、非常に高速なCPUと非常に遅いディスク圧縮を使用すると、書き込みと読み取りにかかる時間が短縮されますが、SSDの場合非常に高速でCPUが非常に遅いので、書き込みがはるかに遅くなります。

私がその時点で意味する高速または低速のCPUについて話すとき、CPUは「数学」またはその他のプロセスによって使用されている可能性があるため、紙のCPU仕様ではなく、常に無料のCPUについて考えます。ディスク/ SSDについても同様です。複数のプロセスで使用されている。

7ZipがLZMA2を使用して別のディスクから巨大なファイルを書き込んでいる場合、CPUを大量に使用するため、同時にNTFS圧縮ファイルをコピーしている場合、CPUの空き容量がないため、NTFSがない場合よりも遅くなります7ZipがCPUの使用を終了するとすぐに、そのようなCPUはNTFS圧縮をより高速に実行できるようになり、その時点でNTFS圧縮はより高速に処理を実行できます。

個人的にはNTFS圧縮を使用することはありません。PISMOファイルマウントPFOコンテナーを好んで使用します（圧縮あり。また、オンザフライで、アプリに対して透過的に暗号化できます）。これにより、読み取り中に圧縮率が大幅に向上し、CPUへの影響が少なくなります。オンザフライで書き込み、使用前に解凍する必要はありません。マウントして読み取りおよび書き込みモードで使用するだけです。

PISMOはディスクに書き込む前にRAMで圧縮を行うので、SSDをより長く持続させることができます。NTFS圧縮のテストでは、最初に非圧縮でデータをディスクに2回送信し、その後圧縮できる場合は圧縮形式で上書きされます。 。

SSDのNTFS圧縮書き込み速度が、ファイルのある非圧縮ファイルの約1/2で、サイズの1/2近くまたはそれ以下の圧縮サイズで圧縮するよりもなぜですか？AMD Threadripper 2950（32コアおよび64スレッド）では、128GiBのRAM（高速CPU、非常に高速なCPU）を使用しているため、使用率が1％未満なので、SSDの最大セキュリティ速度よりも高速に圧縮できるCPUがたくさんあります。 64KiBブロックが圧縮されていないディスクに送信された後にNTFS圧縮が開始し、圧縮バージョンで上書きされます...ホストのLinuxとゲストのWindowsを実行している仮想マシンで実行すると、Linuxキャッシュから、このようなクラスターが2回書き込まれることが通知されます、速度ははるかに高速です（LinuxはWindowsゲストから送信された非圧縮NTFS書き込みをキャッシュします。圧縮データで上書きされた後、Linuxは非圧縮データをディスクに送信しないため、

私の推奨は、ホストがLinuxである場合は仮想マシンのゲストがWindowsを実行し、CPUが十分に高速でない場合にCPUを使用しない限り、NTFS圧縮を使用しないことです。

最新のSSDには巨大な内部RAMキャッシュがあるため、NTFS圧縮によって発生する書き込みと上書きはSSD内部キャッシュシステムによって軽減できます。

私のテストは、SSD内のキャッシュ用の内部RAMのない「きれいな」SSDで行われました。RAMキャッシュのあるものでそれらを繰り返すと、書き込み速度は速くなりますが、思ったほどではありません。

独自のテストを行い、巨大なファイルサイズを使用します（キャッシュの非表示の結果を回避するために、インストールされているtamよりも大きい）。

ちなみに、一部の人はNTFS圧縮について知らないことがあります... 4KiB以下のファイルは、少なくとも4KiBのサイズを縮小する方法がないため、決してNTFS圧縮を取得できません。

NTFS圧縮は64KiBのブロックを取り、それらを圧縮します。1つのクラスター（4KiB）を削減できる場合、圧縮されて書き込まれます。64KiBは4KiB（連続）の16ブロックです。

圧縮が終了したときの最終的な結果が8KiBのファイルが4KiBを超える場合、クラスターは保存されないため、非圧縮で書き込まれます...など...圧縮は少なくとも4KiBを獲得する必要があります。

ああ、そしてNTFS圧縮の場合、NTFSはクラスターサイズが4KiBでなければなりません。

テストしてみてください：SSDのNTFSで128KiBクラスターを使用すると、書き込みと読み取りの速度が大幅に向上します。

4KiBクラスターを使用したSSD上のファイルシステムは、ほとんどの場合、50％以上の速度を失っています... 512バイトから最大2MiBまでのさまざまなブロックサイズでテストしたベンチマークを参照してください。 64KiB（または128KiB）クラスターサイズの場合の速度は4KiBの場合よりも高速です。

SSDを実際に使用したいですか？ファイルシステムでは4KiBクラスターを使用せず、128KiBを使用してください。

4KiBクラスターは、ファイルの99％以上が128KiB未満の場合にのみ使用してください。

等、など...テスト、テスト、および独自のケースをテストします。

注：128KiBクラスターでWindowsをインストールするとき、または別のWindowsからコンソールモードでdiskpartを使用してシステムNTFSパーティションを作成しますが、インストーラーのグラフィカルパーツでウィンドウをフォーマットしないでください（常に4KiBクラスターNTFSとしてフォーマットされます）。

Windowsはすべて、> 400GiB SSD（SLC）上の128KiBクラスターNTFSパーティションにインストールされています。

物事が明らかになることを願って、M $は圧縮されたNTFSをどのように書き込むかを言っていない、私のテストでは、1回だけではなく（SSDの場合はそれに注意して）2回（64KiB非圧縮、次に<= 60KiB圧縮）書き込むことを示しています。

注意：NTFS圧縮は4KiBクラスターサイズのNTFSパーティションでのみ機能するため、WindowsはNTFS圧縮がないと言っても、いくつかの内部ディレクトリをNTFS圧縮しようとします。

他の人のコメントを見ると、多くの場合、NTFSファイル/フォルダー圧縮がSSDに大きな利点がある最新の開発ツールという最も有用なシナリオを忘れていると思います。私の大学ライセンスのMatlabの（通常のユーザーは読み取り専用）インストールフォルダーに次の量のデータがあります。

28.5 GBデータ30.6 GBディスク上のサイズ729.246ファイルと15.000フォルダが含まれます（!!!）

これは、500 GB SSDを搭載した私のラップトップで、Windowsパーティションは200 GBです。

私はMatlabがこの点で少し極端であることを知っていますが、多くのdevtoolsには同様のプロパティがあります：大量の小さな、非常に圧縮可能なテキストファイル（ヘッダー、コード、XMLファイル）。Intel Quartus FPGA devtool をインストールする直前にMatlabを圧縮していますが、Octaveは次のようにすでに圧縮されています。

ディスク上の1.55 GBのデータサイズ：839 GB 34.362ファイルを含む1.955フォルダ

この内容は1回書き込まれ、プロジェクトのビルド中に何十億回も読み込まれます。それを解凍し、貴重なSSDスペースのおそらく半分を節約するためにCPUパワーをいくらか消費することは完全に理にかなっています。

あなたは知るために2回ベンチマークする必要があります。圧縮。非圧縮。SSDの摩耗を忘れます。ボトルネックが発生しないように、高速なSSDおよびCPUが必要です。

512GBのSSDは最近50ドルです。私にとってこれまでで最も速いディスクアクセスは、可能な場合はLinuxとLIFOディスクキューメカニズムを使用することです。CFQではなく。

Windows 10では、私のラップトップに12GBのRAMがインストールされていると、無限のディスクアクティビティが発生します。Linuxはロードされ、その後ディスクアクセスはほとんど発生しません。あなたがそれを始めない限り。Windowsには、目に見えるタスクがなくても自分自身を忙しく保つ方法があります。