web-dev-qa-db-ja.com

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

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

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

時間がかかりすぎます。 topでプロセスを確認します。 bzip2プロセスは、1つのコアの約95％とpostgres 5％を占めます。 waエントリが少なくなっています。これは、ディスクがボトルネックではないことを意味します。

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

多分bzip2にもっと多くのコアを使わせてください。サーバーには16コアがあります。

またはbzip2の代替を使用しますか？

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

performancepostgresqlgzip
33
guettli

周りには多くの圧縮アルゴリズムがあり、_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がおそらく最善の策です。

pdate：brotli（TOOGAMの回答を参照）の結果を表に追加しました。 brotlis圧縮品質設定は、圧縮率と速度に非常に大きな影響を与えるため、3つの設定（_q0_、_q1_、および_q11_）を追加しました。デフォルトは_q11_ですが、非常に低速であり、xzよりもさらに悪いです。 _q1_は非常によく見えます。 gzipと同じ圧縮率ですが、4〜5倍高速です。

pdate： _lbzip2_（gmathtsコメントを参照）とzstd（Johnnyのコメントを参照）をテーブルに追加し、圧縮速度でソートしました。 _lbzip2_は、_bzip2_ファミリーを_pbzip2_の3倍の速さで圧縮し、高い圧縮率で実行に戻します！ zstdも適切に見えますが、比率と速度の両方でbrotli (q1)に勝っています。

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

51
marcelm

Pbzip2を使用します。

manual は言う：

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

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

37
ThoriumBR
  • Googleのブロトリは、いくつかの印象的な圧縮、いくつかの印象的な速度、そしておそらくこれらの機能の両方の最も印象的な組み合わせ/バランスを備えているため、最近ブラウザー内でいくつかの幅広いサポートを得た新しいフォーマットです。

    いくつかのデータ：

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

    • 例： このグラフ BrotliがBzip2より約6〜14速いことを示す数値を報告します。

    CanIUse.com：feature：brotli はMicrosoft Edge、Mozilla Firefox、Google Chrome、Apple Safari、Opera（but 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のバージョンです。

8
TOOGAM

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

もっと深刻なことに、それは実際にはかなり良いです。私は今それをすべてのために使用します。それが機能するだけであり、大規模な比率と速度のトレードを可能にします（ほとんどの場合、ストレージは安価ですが速度がボトルネックなので、とにかく速度はサイズよりも重要です）。
bzip2と同等の全体的な圧縮を実現する圧縮レベルでは、大幅に高速になり、CPU時間をいくらか増やしたい場合は、ほぼLZMAと同様の結果を実現します（ただし、bzip2よりも遅くなります）。ひどく悪い圧縮率では、bzip2や他の主流の代替よりもはるかに高速です。

これで、SQLダンプを圧縮しています。これは、圧縮するのが非常に簡単で、圧縮するのが非常に簡単です。最悪のコンプレッサーでさえ、その種のデータでは十分に得点します。
したがって、より低い圧縮レベルでzstdを実行できます。これにより、何十回も実行され、95を達成します。 -99％そのデータに同じ圧縮。

おまけとして、これを頻繁に実行し、追加の時間を費やしたい場合は、事前にzstdコンプレッサーを「トレーニング」すると、圧縮率と速度の両方が向上します。トレーニングが適切に機能するためには、全体ではなく、個別のレコードをフィードする必要があることに注意してください。このツールの動作方法では、1つの巨大なブロブではなく、トレーニングのために多くの小さくていくぶん似たサンプルが必要です。

2
Damon

ブロックサイズを調整（小さく）すると、圧縮時間に大きな影響を与える可能性があります。

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

デフォルトの（最大の）ブロックサイズ（--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

文書に次のように書かれていることを考えると、これは少し意外な発見でした。

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

1
Jakub Kukul