最新のシステムでは、出力ストリームを圧縮することでローカル ハードディスクの書き込み速度を改善できますか?
この質問は、プログラムが約 1 ～ 2 GB のテキスト ログ データをシリアルに生成し、ハード ディスク上の生のテキスト ファイルにダンプする作業を行っているケースから派生したもので、IO バウンドだと思います。データがディスクに送られる前にデータを圧縮することで実行時間を短縮できると期待できますか?それとも、圧縮のオーバーヘッドが得られる利益を食いつぶしてしまうのでしょうか? アイドル状態の 2 番目のコアがあると、これに影響しますか?
これは、データの生成にどれだけの CPU が使用されているかによって影響を受けることがわかっているので、どれだけのアイドル CPU 時間が必要になるかについての経験則が適切です。
誰かが圧縮を使用してデータベースの読み取り速度を向上させたというビデオ トークを思い出しますが、IIRC 圧縮は解凍よりもはるかに CPU を集中的に使用します。
はい、はい、はい、絶対に。
このように考えてみてください: 最大連続ディスク書き込み速度を 1 秒あたりのメガバイト数で表します。（先に進んで測定し、巨大なfwriteか何かの時間を計ってください。） 100mb / sとしましょう。ここで、CPU 速度をメガヘルツで表します。3Ghz = 3000MHz としましょう。CPU 速度をディスク書き込み速度で割ります。これは、CPU がアイドル状態で費やしているサイクル数であり、 1 バイトあたりの圧縮に費やすことができます。この場合、3000/100 = 1 バイトあたり 30 サイクルです。
データを 25% 圧縮して有効な 125 mb/s の書き込み速度を実現できるアルゴリズムがある場合、1 バイトあたり 24 サイクルで実行でき、CPU は他に何もしていないため、基本的に無料です。ディスクがチャーンするのを待っている間。1 バイトあたり 24 サイクル = 128 バイトのキャッシュ ラインあたり 3072 サイクル、簡単に実現できます。
光学メディアを読み取るときは、常にこれを行います。
アイドル状態の 2 番目のコアがあれば、さらに簡単です。ログバッファをそのコアのスレッドに渡すだけで、他に何もしていないため、データを圧縮するのに時間がかかる場合があります! 唯一のトリッキーなビットは、プロデューサー スレッド (ログを作成するスレッド) が消費者スレッド (ディスクに書き込むスレッド) のバッファーをミューテックスで待機しないように、実際にバッファーのリングを持ちたいことです。保持しています。
はい、これは少なくとも 10 年間は当てはまりました。それに関するオペレーティングシステムの論文があります。クリス・スモールがそれらのいくつかに取り組んだ可能性があると思います.
速度については、gzip/zlib低品質レベルでの圧縮はかなり高速です。それが十分に速くない場合は、FastLZを試すことができます。追加のコアを使用する簡単な方法は、 をpopen(3)介して出力を送信するために使用することgzipです。
Stony BrookのFilesystems and storage lab は、今年の IBMのSYSTOR システム研究会議で、サーバー システム上のファイル データ圧縮に関するかなり広範なパフォーマンス (およびエネルギー) 評価を発表しました。
結果は、
たとえば、この論文の測定では、テキスト ワークロードを使用し、lzop を使用するサーバー環境で圧縮作業を少なくすると、通常の書き込みよりも高速になりますが、bzip と gz はそうではありません。
特定の設定で、試して測定する必要があります。実際にはパフォーマンスが向上する可能性がありますが、常にそうであるとは限りません。
価値があるのは、Sun のファイルシステム ZFS には、実際の例として、オーバーヘッドを大幅に増加させることなく、オンザフライ圧縮を有効にしてディスク IO の量を減らす機能があります。
WindowsはすでにNTFSでファイル圧縮をサポートしているため、ファイル属性に「圧縮」フラグを設定するだけです。次に、それが価値があるかどうかを測定できます。
CPUは、ハードドライブへのアクセスよりも速い速度で成長しています。80年代にさえ、多くの圧縮ファイルをディスクから読み取り、元の（非圧縮）ファイルを読み取るよりも短い時間で解凍することができました。それは変わっていないでしょう。
ただし、一般的に、最近では、圧縮/解凍は、たとえばデータベースI/Oレイヤーで作成するよりも低いレベルで処理されます。
2番目のコアの有用性については、システムが他の多くのことも実行する場合にのみ重要です。追加のCPUを利用するには、プログラムをマルチスレッド化する必要があります。
データをバイナリ形式でログに記録すると、すぐに改善される場合があります。ディスクへの書き込みが少なくなり、CPU が数値をテキストに変換するのに費やす時間が少なくなります。人々がログを読む場合には役に立たないかもしれませんが、圧縮されたログを読むこともできません。
この特定のマシンがIOバウンドであることが多い場合、それを高速化する別の方法は、RAIDアレイをインストールすることです。これにより、すべてのプログラムとすべての種類のデータ（非圧縮性データも含む）が高速化されます。
たとえば、合計4つのディスクを備えた一般的なRAID 1 + 0構成では、ほぼ2倍のスピードアップが得られます。
合計4つのディスクを備えたほぼ同じくらい人気のあるRAID5構成により、すべてがほぼ3倍のスピードアップを実現します。
単一ドライブの8倍の速度でRAIDアレイをセットアップするのは比較的簡単です。
一方、高い圧縮率は、明らかにそれほど単純ではありません。「単に」6.30を1に圧縮すると、圧縮の現在の世界記録を破ったことに対する賞金が与えられます（ハッター賞）。
テキストだけの場合は、圧縮が確実に役立ちます。圧縮を安価にする圧縮アルゴリズムと設定を選択するだけです。「gzip」は「bzip2」よりも安価で、速度や圧縮率を優先するように微調整できるパラメーターがあります。
人間が読めるテキストをハード ドライブに保存するために I/O バウンドになっている場合は、圧縮によって総実行時間が短縮されると思います。
アイドル状態の 2 GHz コアと、比較的高速な 100 MB/秒のストリーミング ハード ドライブがある場合、正味のログ時間を半分にするには、少なくとも 2:1 の圧縮が必要であり、コンプレッサーが圧縮を検討するために圧縮されていないバイトあたり約 10 CPU サイクル以下が必要です。データ。デュアル パイプ プロセッサの場合、これは (非常に大まかに) 1 バイトあたり 20 命令です。
LZRW1-A (最速の圧縮アルゴリズムの 1 つ) は 1 バイトあたり 10 ～ 20 の命令を使用し、一般的な英語のテキストを約 2:1 に圧縮することがわかります。上限 (1 バイトあたり 20 命令) では、IO バウンドと CPU バウンドの間の境界にいます。中間および下端では、まだ IO バウンドであるため、もう少し洗練されたコンプレッサーがデータをもう少し熟考するために利用できるサイクルが (それほど多くはありませんが) あります。
より一般的な最上位以外のハード ドライブを使用している場合、または他の理由 (断片化、ディスクを使用するその他のマルチタスク プロセスなど) でハード ドライブが遅い場合は、より多くの時間を費やすことができます。データを熟考するための洗練されたコンプレッサー。
圧縮パーティションを設定し、データをそのパーティションに保存し (デバイス ドライバーで圧縮する)、速度を元の速度と比較することを検討してください。プログラムを変更して圧縮アルゴリズムにリンクするよりも、時間がかからず、新しいバグが発生する可能性も低くなります。
FUSE に基づいた圧縮ファイル システムのリストが表示され、NTFS も圧縮パーティションをサポートしていると聞きました。
これは多くの要因に依存し、正解は 1 つではないと思います。これは次のようになります。
この目的専用に使用できる CPU 帯域幅を考慮して、ディスクの raw 書き込みパフォーマンスに達成している圧縮率 (または取得しようとしている速度の倍数) を掛けるよりも速く raw データを圧縮できますか?
今日のデータ書き込み速度が数十メガバイト/秒と比較的高いことを考えると、これは克服するための非常に高いハードルです。他のいくつかの回答のポイントまで、簡単に圧縮できるデータが必要になる可能性が高く、合理性タイプの実験のテストでベンチマークを実行して調べる必要があります。
追加のコアに関する特定の意見 (推測!?) に関連して。データの圧縮をスレッド化してコアに供給し続ける場合 (テキストの圧縮率が高い場合)、そのような手法が実を結ぶ可能性があります。しかし、これは単なる推測です。ディスクへの書き込みと圧縮操作を交互に行うシングル スレッド アプリケーションでは、その可能性ははるかに低いと思われます。
これは、かなりの数のアプリケーションでパフォーマンスを向上させることができるものでした。今日、それが報われる可能性は低いと思いますが、特定の状況では、特にログに記録しているデータが簡単に圧縮できる場合は、そうなる可能性があります。
ただし、Shog9がコメントしたように：
ここでは経験則は役に立ちません。それはあなたのディスク、あなたの CPU、そしてあなたのデータです。テスト ケースを設定し、圧縮の有無にかかわらずスループットと CPU 負荷を測定します。トレードオフの価値があるかどうかを確認してください。