このトピックディスク アクセス パフォーマンスを改善する方法として HDD 上の NTFS 圧縮について説明し、その方法が不十分な場合が多いと結論付けています。しかし、私は常に圧縮をスペースを節約する方法と見なし、その点での圧縮の有効性を学びました。そして今、私はスペースが高価で、たとえば 1 つのクラスターではなく 2 つのクラスターの読み取り/書き込みによるパフォーマンスの低下がはるかに少ない SSD を使用しています。
一方、SSD は HDD よりもはるかに高速なので、スループットが高くなると CPU 使用率も高くなると予想されます。これは問題になるでしょうか? この件について他に何か考えはありますか?
スペース節約効果は気に入っています。それほど大きくはありませんが、効果はあります。ただし、パフォーマンスが気になる場合は、オフにすることをお勧めします。
答え1
マイクロソフト少し前にブログに書いた:
NTFS は、データ ストリームを CU に分割してファイルを圧縮します (これは、スパース ファイルの動作に似ています)。ストリーム コンテンツが作成または変更されると、データ ストリーム内の各 CU が個別に圧縮されます。圧縮によって 1 つ以上のクラスターが削減される場合、圧縮されたユニットは圧縮された形式でディスクに書き込まれます。次に、アラインメントの目的で、スパース VCN 範囲が圧縮された VCN 範囲の最後に追加されます (以下の例を参照)。データが 1 つのクラスターのサイズを削減するほど圧縮されない場合は、CU 全体が圧縮されていない形式でディスクに書き込まれます。
この設計により、ファイル内の任意の VCN にアクセスするために 1 つの CU のみを解凍すればよいため、ランダム アクセスが非常に高速になります。残念ながら、シーケンシャル操作 (バックアップなど) を実行するには多数の CU を解凍する必要があるため、大規模なシーケンシャル アクセスは比較的遅くなります。
そして、KBの記事ではこう書いている:
NTFS ファイル システムの圧縮によりディスク領域を節約できますが、データを圧縮するとパフォーマンスに悪影響を与える可能性があります。NTFS 圧縮には、次のパフォーマンス特性があります。圧縮された NTFS ファイルを別のフォルダーにコピーまたは移動すると、NTFS はファイルを解凍し、新しい場所にコピーまたは移動してから、ファイルを再圧縮します。この動作は、同じコンピューター上のフォルダー間でファイルをコピーまたは移動した場合にも発生します。圧縮ファイルは、ネットワーク経由でコピーされる前にも展開されるため、NTFS 圧縮ではネットワーク帯域幅が節約されません。
NTFS圧縮はプロセッサを集中的に使用するため、プロセッサの制約を受けることが多いサーバーではパフォーマンス コストがより顕著になります。書き込みトラフィックが多く、負荷の高いサーバーは、データ圧縮に適していません。ただし、読み取り専用、読み取りが主、または負荷が軽いサーバーでは、パフォーマンスの大幅な低下は発生しない可能性があります。
トランザクション ログを使用し、データベースまたはログに継続的に書き込むプログラムを実行する場合は、圧縮されていないボリュームにファイルを保存するようにプログラムを構成します。プログラムが圧縮ファイル内のマップされたセクションを通じてデータを変更すると、マップされたライターが書き込むよりも速く、プログラムによって「ダーティ」ページが生成される可能性があります。この問題のため、Microsoft Message Queuing (MSMQ とも呼ばれます) などのプログラムは NTFS 圧縮では動作しません。
ユーザーのホーム フォルダーと移動プロファイルでは読み取りおよび書き込み操作が頻繁に行われるため、Microsoft では、親フォルダーまたはボリューム ルートに NTFS 圧縮が適用されていないボリュームにユーザーのホーム フォルダーと移動プロファイルを配置することをお勧めします。
まとめ：
変更されない小さなファイルのみを圧縮します (読み取りのみで書き込みは行いません)。読み取りは高速ですが、書き込みには解凍と新しい圧縮が必要で、CPU パワーを消費し、ストレージ タイプはそれほど重要ではないためです。
答え2
クラウディオは多くのことを詳しく述べているので、私も彼の意見を引用しますが、彼の言うことを試した後、同じ効果を実感しました。
SSD の場合、NTFS 圧縮は使用できません。
ここで、そのような断言の動機をいくつか挙げてみたいと思います。
理由 1: 書き込みが 2 回行われるため、SSD の性能がはるかに早く低下します。NTFS 圧縮では、圧縮を開始する前に常に非圧縮データが RAM に書き込まれ、圧縮されたデータが少なくとも 4KiB 増加する場合にのみ、圧縮されたデータを再書き込みします。
理由 2: SSD で NTFS 4KiB クラスターを使用すると、SSD の速度が 50% 低下します。ベンチマークを確認すると、128KiB ブロックを使用すると、4KiB ブロックを使用する場合よりも SSD が 2 倍高速になることがわかります。また、NTFS 圧縮は 4KiB クラスターの NTFS パーティションでのみ使用できます。
目的 3: オンザフライ圧縮や暗号化として見られるコンテナを作成できるコンテナ (PISMO ファイル マウントなど) があります。このようなコンテナは RAM 上で圧縮を実行し、圧縮形式で再書き込みする前に非圧縮データをディスクに送信しません。さらに、PISMO は NTFS よりも優れた圧縮率を実現します。
動機は他にもたくさんありますが、最も重要なのはこれらです。
もう 1 つのポイントは速度です。圧縮はすべて CPU で行われるため、非常に高速な CPU がない場合 (NTFS ではモノスレッドが使用され、一部のコンテナーではマルチスレッドが使用されます)、圧縮時に読み取り/書き込みが非常に遅くなります。最悪なのは、非常に高速な CPU があっても、それが他の処理 (レンダリング、トランスコーディングなど) に使用されている場合は圧縮に CPU が残っていないため、やはりパフォーマンスが低下します。
NTFS 圧縮は、CPU をあまり使用していない従来の低速ディスクにのみ適していますが、各 64KiB ブロック (圧縮されているかどうかに関係なく) は 64KiB の倍数の位置に書き込まれるため、書き込みのたびに (ファイル レベルで) 適切なデフラグが必要になります。このようなフラグメントをパックする唯一の方法は、圧縮後 (または圧縮フォルダーに書き込んだ後)、このようなファイルのデフラグを実行することです。
PD: ここで話題にしているのは仮想マシン内の Windows ではなく、実際のハードウェア上の Windows であることに注意してください。重要なのは、誰が物理メディアに書き込むかです。他のデバイスには、影響を軽減し、大幅に改善できるキャッシュ レイヤーがある可能性があります。
答え3
他の人のコメントを見ると、NTFSファイル/フォルダ圧縮がSSDで大きな利点となる最も便利なシナリオ、つまり最新の開発ツールを人々が忘れているように思います。大学ライセンスの Matlabインストール フォルダー (一般ユーザーの場合は読み取り専用) には、次の量のデータが含まれています。
28.5 GB データ 30.6 GB ディスク上のサイズ 729,246 個のファイルと 15,000 個のフォルダーが含まれています (!!!)
これは、Windows パーティションが 200 GB の 500 GB SSD を搭載したラップトップです。
Matlabはこの点では少し極端だとは思いますが、多くの開発ツールには同様の特性があります。つまり、大量の小さくて圧縮率の高いテキストファイル（ヘッダー、コード、XMLファイル）です。私は現在、インストール前にMatlabを圧縮しています。インテル Quartus FPGA開発ツール、そしてオクターブすでに次のように圧縮されています。
1.55 GB ディスク上のデータサイズ: 839 GB 34.362 個のファイルと 1.955 個のフォルダが含まれています
これは一度書かれ、プロジェクトのビルド中に何度も読み込まれる。いくつかのCPU パワーを使用して解凍し、貴重な SSD スペースをおそらく半分節約します。
答え4
確認するには、ベンチマークを 2 回実行する必要があります。圧縮、非圧縮。SSD の摩耗は忘れてください。ボトルネックが発生しないように、高速な SSD と CPU が必要です。
512GB の SSD は、今では 50 ドルです。これまでのところ、私にとって最も高速なディスク アクセスは、可能な場合は Linux を使用し、CFQ ではなく LIFO ディスク キュー メカニズムを使用することです。
私のラップトップに 12GB の RAM が搭載されている場合、Windows 10 はディスク アクティビティを無限に発生させます。Linux Mint が読み込まれると、その後はディスク アクセスがほとんど発生しません。開始しない限りは。Windows には、目に見えるタスクがなくても、常にビジー状態を維持する方法があります。