bzip2が遅すぎる。複数のコアが利用可能

私はこのコマンドを実行しています：

pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2

時間がかかりすぎます。でプロセスを見ますtop。bzip2プロセスには、1つのコアの約95％とpostgresの5％が必要です。waエントリーは低いです。これは、ディスクがボトルネックではないことを意味します。

パフォーマンスを向上させるにはどうすればよいですか？

bzip2がより多くのコアを使用するようにします。サーバーには16個のコアがあります。

または、bzip2の代わりに使用しますか？

パフォーマンスを向上させるにはどうすればよいですか？

周囲には多くの圧縮アルゴリズムがありbzip2、遅いアルゴリズムの1つです。プレーンgzipは、通常、圧縮がそれほど悪くない場合に、著しく高速になる傾向があります。速度が最も重要な場合、lzop私のお気に入りです。圧縮率は低いですが、非常に高速です。

私はいくつかの楽しみを持ち、それらの並列実装を含むいくつかのアルゴリズムを比較することにしました。入力ファイルはpg_dumpall、ワークステーションでのコマンドの出力、1913 MBのSQLファイルです。ハードウェアは古いクアッドコアi5です。時間は、圧縮のみの実時間です。並列実装は、4つのコアすべてを使用するように設定されています。圧縮速度でソートされたテーブル。

Algorithm     Compressed size        Compression          Decompression

lzop           398MB    20.8%      4.2s    455.6MB/s     3.1s    617.3MB/s
lz4            416MB    21.7%      4.5s    424.2MB/s     1.6s   1181.3MB/s
brotli (q0)    307MB    16.1%      7.3s    262.1MB/s     4.9s    390.5MB/s
brotli (q1)    234MB    12.2%      8.7s    220.0MB/s     4.9s    390.5MB/s
zstd           266MB    13.9%     11.9s    161.1MB/s     3.5s    539.5MB/s
pigz (x4)      232MB    12.1%     13.1s    146.1MB/s     4.2s    455.6MB/s
gzip           232MB    12.1%     39.1s     48.9MB/s     9.2s    208.0MB/s
lbzip2 (x4)    188MB     9.9%     42.0s     45.6MB/s    13.2s    144.9MB/s
pbzip2 (x4)    189MB     9.9%    117.5s     16.3MB/s    20.1s     95.2MB/s
bzip2          189MB     9.9%    273.4s      7.0MB/s    42.8s     44.7MB/s
pixz (x4)      132MB     6.9%    456.3s      4.2MB/s     7.9s    242.2MB/s
xz             132MB     6.9%   1027.8s      1.9MB/s    17.3s    110.6MB/s
brotli (q11)   141MB     7.4%   4979.2s      0.4MB/s     3.6s    531.6MB/s

サーバーの16コアが十分にアイドル状態で、すべてを圧縮に使用できるpbzip2場合、おそらく非常に大幅な高速化が得られます。ただし、さらに高速が必要であり、最大20％のサイズのファイルを許容できgzipます。おそらく最善の方法です。

更新：brotli結果を表に追加しました（TOOGAMの回答を参照）。brotli私は3つの設定を追加したので、sの圧縮品質設定は、圧縮率と速度に非常に大きな影響を持っている（q0、q1およびq11）。デフォルトはですがq11、それは非常に遅く、さらに悪いですxz。q1でもとてもよさそうです。と同じ圧縮率ですがgzip、4〜5倍高速です。

更新：lbzip2（gmathtsコメントを参照）およびzstd（ジョニーのコメント）をテーブルに追加し、圧縮速度でソートしました。優れた圧縮率の3倍の速度で圧縮することでlbzip2、bzip2ファミリーを元の状態に戻しpbzip2ます！zstdまた、合理的に見えますがbrotli (q1)、比率と速度の両方で打ち負かされています。

プレーンgzipが最善の策であるという私の最初の結論は、ほとんどばかげているように見え始めています。ユビキタスのために、それはまだ打ち負かすことはできません;）

pbzip2を使用します。

マニュアルには書かれています：

pbzip2は、pthreadを使用し、SMPマシンでほぼ線形の高速化を実現するbzip2ブロックソートファイルコンプレッサーの並列実装です。このバージョンの出力は、bzip2 v1.0.2以降と完全に互換性があります（つまり、pbzip2で圧縮されたものはすべて、bzip2で解凍できます）。

使用しているプロセッサの数を自動検出し、それに応じてスレッドを作成します。

• Googleのbrotliは、いくつかの印象的な圧縮、印象的な速度、そしておそらくこれらの機能の最も印象的な組み合わせ/バランスを備えているため、最近ブラウザ内である程度のサポートを得た新しい形式です。

  一部のデータ：

  Brotli、Deflate、Zopfli、LZMA、LZHAM、Bzip2圧縮アルゴリズムの比較

  • たとえば、BrotliがBzip2よりも約6〜14速いことを示す数値を報告するこのチャート。

  CanIUse.com：機能：brotliは、Microsoft Edge、Mozilla Firefox、Google Chrome、Apple Safari、Opera（ただし、Opera MiniまたはMicrosoft Internet Explorerではない）によるサポートを示しています。

  比較：Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2

  • 圧縮速度を探している場合、探しているのは、このチャートのさらに右の行です。（このグラフの上部のエントリは、圧縮率が高いことを示しています。より高い=より高いです。ただし、圧縮速度が優先される場合は、グラフのさらに右に到達する行により注意を払う必要があります。）
  比較：7-Zip ZStandardメソッドの圧縮率と圧縮速度

• FacebookのZStandardはもう1つのオプションです。ビットを削減することを目指していますが、予測ミスを減らす方法でデータを保存することに重点を置いており、高速化を実現しています。ホームページは 次のとおりです。ZStandardを使用したデータ圧縮の小型化と高速化
• Lizardは、BrotliやZStandardほどの圧縮率は得られませんが、圧縮率がやや近く、かなり高速になる場合があります（少なくとも、速度についてのこのグラフによると、圧縮解除を報告しています）

オペレーティングシステムについては言及していません。Windowsの場合、7-Zip with ZStandard（Releases）は7-Zipのバージョンであり、これらすべてのアルゴリズムの使用をサポートするように変更されています。

zstdを使用します。Facebookに十分であれば、おそらくあなたにも十分でしょう。

もっと深刻な注意点として、実際にはかなり良いです。私は今それをすべてのものに使用しています。それはうまく機能するためであり、大規模で速度と比率を交換することができます（ほとんどの場合、ストレージは安価であるため速度はサイズよりも重要ですが、速度はボトルネックです）。
bzip2に匹敵する全体的な圧縮を達成する圧縮レベルでは、大幅に高速になり、CPU時間に余分な費用を払っても構わない場合、LZMAと同様の結果をほぼ達成できます（ただし、bzip2よりも遅くなります）。圧縮率がわずかに低い場合、bzip2または他の主流の代替よりもはるかに高速です。

今、SQLダンプを圧縮しています。これは、可能な限り圧縮するのは非常に面倒なことです。最も貧弱なコンプレッサーでさえ、この種のデータで高いスコアを獲得しています。
そのzstdため、より低い圧縮レベルで実行できます。これにより、何十倍も高速に実行され、そのデータで95〜99％の同じ圧縮を達成できます。

ボーナスとして、これを頻繁に行って余分な時間を投資したい場合は、zstd事前にコンプレッサーを「トレーニング」することができます。これにより、圧縮率と速度の両方が向上します。トレーニングがうまく機能するためには、全体ではなく個々の記録をフィードする必要があることに注意してください。ツールの動作方法は、1つの巨大なブロブではなく、トレーニング用の多くの小さくてやや似たサンプルを想定しています。

ブロックサイズの調整（低下）は、圧縮時間に大きな影響を与えるようです。

以下は、私のマシンで行った実験の結果です。timeコマンドを使用して実行時間を測定しました。input.txtは、任意のjsonレコードを含む最大250 MBのテキストファイルです。

デフォルト（最大）ブロックサイズを使用する（--bestデフォルトの動作を選択するだけです）：

# time cat input.txt | bzip2 --best > input-compressed-best.txt.bz

real    0m48.918s
user    0m48.397s
sys     0m0.767s

最小ブロックサイズ（--fast引数）を使用：

# time cat input.txt | bzip2 --fast > input-compressed-fast.txt.bz

real    0m33.859s
user    0m33.571s
sys     0m0.741s

これは、驚くべき発見でした。

圧縮および解凍の速度は、ブロックサイズの影響をほとんど受けません