最速のGZIPユーティリティ

18

最速のgzip（またはzip）ユーティリティを探しています。LVMボリュームは95％が空白0であるため、圧縮は非常に簡単です。私は最も高速なソリューションを探していますが、0「s」以外の圧縮はあまり気にしません。

私は知っていますgzip -1（と同じですgzip --fast）が、もっと速い方法があるかどうか疑問に思っていました。

ありがとう。

編集： いくつかのテストの後、私は比較gzip -1、lzop -1そしてpigz -1お互いに次のような結果になりました。

PIGZ：

time dd if=/dev/VPS/snap | pigz -1 | ssh backup-server "dd of=/home/backupvps/snap.pigz"

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 2086.87 seconds, 25.7 MB/s
7093985+266013 records in
7163950+1 records out
3667942715 bytes (3.7 GB) copied, 2085.75 seconds, 1.8 MB/s

real    34m47.147s

LZOP：

time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop" 

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1829.31 seconds, 29.3 MB/s
7914243+311979 records in
7937728+1 records out
4064117245 bytes (4.1 GB) copied, 1828.08 seconds, 2.2 MB/s

real    30m29.430s

GZIP：

time dd if=/dev/VPS/snap | gzip -1 | ssh backup-server "dd of=/home/backupvps/snap_gzip.img.gz

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1843.61 seconds, 29.1 MB/s
7176193+42 records in
7176214+1 records out
3674221747 bytes (3.7 GB) copied, 1842.09 seconds, 2.0 MB/s

real    30m43.846s

編集2：

これは私の最初の質問とは多少関係ありませんが、time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"（ブロックサイズを16Mに変更して）使用すると、時間はreal 18m22.442s！

linux  compression  gzip 
— Devator
ソース
1
注意してくださいtime。このような方法で使用するのは多少不公平です。使用されるddのスループットはpigz他の2つよりも低くなります。
— ヘンク
@Devator：タイミングを見ると、現在暗号化されたsshトンネルを介してバイトをプッシュすることがボトルネックであると結論付けることができます。「-c」（圧縮）フラグを指定してsshを使用し、プリコンプレッサーを式から除外しようとしましたか？より高速な暗号化アルゴリズムに切り替えることもできます。それとは別に：ssh-tunnelを使用せずにベンチマークを再設定（たとえば、出力シンクとして/ dev / nullを使用）
— akira
補足として、スパースファイルを使用できますか？その後、ゼロはディスク上のスペースを占有しません。ゼロは、ファイルシステムドライバによって補間されるのであなたの圧縮も速いだろう（と、ディスクから読み取る必要がありません。）
— リー・アウン・イップ
@ Li-aungYip「ファイル」はLVMボリュームなので、そうは思いません。
— -Devator
ああ、分かった。続ける！
— 李アウンイップ

回答:

23

私は個人的にはまだ使用していませんが、パラレルgzipを使用すると、少し速度が上がると思います。

gzipの並列実装の略であるpigzは、データを圧縮するときに複数のプロセッサと複数のコアを活用してgzipを完全に機能させる代替物です。

— パスカル
ソース
1
私は日常的に使用していますが、複数のコアが利用可能な場合はpigzを絶対にお勧めします。これは、圧縮レベルを変更する以外に、圧縮を高速化する最もアクセスしやすく簡単な手段です。
— jgrundstad
3
このサイトは少し奇妙に見えます。だまされてはいけません、pigzはgzipとzlibの開発者であるMark Adlerによって書かれています。
— so_mv
プロジェクトはこの時点で放棄されているようです。
— AlexLordThorsen
私はそれを「安定した」ものと考えることを好みます。頻繁には更新されませんが、更新は行われます。
— アランデス
7

Parallel Gzip（Pascalがリンクしている）またはParallel BZIPを試すことができます。
理論的には、BZIPはテキストに対してはるかに優れているため、pbzipを試してみてください。

— アパッチ
ソース
2

ディスクは30MB / sに制限されています

すべてのコンプレッサーは十分に機能します。少し遅いが遍在するbzip2を使用して、ネットワーク転送を削減することもできます。

$dd if=/dev/zero bs=2M count=512 | pigz -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 9.12679 s, 118 MB/s
8192+7909 records in
9488+1 records out
4857870 bytes (4.9 MB) copied, 9.13024 s, 532 kB/s
$dd if=/dev/zero bs=2M count=512 | bzip2 -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 37.4471 s, 28.7 MB/s
12+1 records in
12+1 records out
6533 bytes (6.5 kB) copied, 37.4981 s, 0.2 kB/s
$dd if=/dev/zero bs=2M count=512 | gzip -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 14.305 s, 75.1 MB/s
9147+1 records in
9147+1 records out
4683762 bytes (4.7 MB) copied, 14.3048 s, 327 kB/s

rsyncを検討しましたか？これはチェックサムを実行してから、差分のみをgzipします。

— ZaB
ソース
1
私のディスクは30 MB / sに制限されていません。テストを実行しました：pigz -1: 1073741824 bytes (1.1 GB) copied, 8.6779 seconds, 124 MB/sとgzip -1: 1073741824 bytes (1.1 GB) copied, 11.6724 seconds, 92.0 MB/s。私はrsyncについて考えましたが、それはファイルの違いをチェックし、ほとんどの場合多くの場合変更されているので、おそらく助けにはなりません。
— -Devator
ゼロを転送する場合は、bzip2エンコーディングがどれほど印象的かを確認してください。どちらの側で速度を測定するか.... 4Mbit / sのpigzは、一般的なDSL回線には多すぎるかもしれません...ディスクがそんなに速い場合はさらに悪化します。
— ZaB
2

Re：lzopのstd configの方が遅い...微調整は半分の時間で済みます。しかし、bloscと呼ばれるさらに高速な置換があります。

https://github.com/FrancescAlted/blosc

うーん...これを投稿して返信するのにかかった時間は、おそらくあなたが得る時間の節約の少なくとも2倍です...さて、私のカーネルを再コンパイルして2秒のブート時間から別の.1を削るのを許してください。

— テクノサウルス
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.