web-dev-qa-db-ja.com

多数の大きなファイルを高速に圧縮する

毎日約200 GBのログデータが生成され、約150の異なるログファイルに分散されています。

ファイルを一時的な場所に移動し、一時ディレクトリでtar-bz2を実行するスクリプトがあります。

200 GBのログが約12〜15 GBに圧縮されるので、良い結果が得られます。

問題は、ファイルの圧縮に永遠にかかることです。 cron ジョブは毎日午前2:30に実行され、午後5：00-6：00まで実行され続けます。

圧縮の速度を向上させ、ジョブをより速く完了する方法はありますか？何か案は？

他のプロセスやすべてについて心配する必要はありません。圧縮が行われる場所は [〜＃〜] nas [〜＃〜] であり、mount NAS専用の [〜＃〜] vm [〜＃〜] で圧縮スクリプトを実行します。

参考のために top の出力を次に示します。

top - 15:53:50 up 1093 days,  6:36,  1 user,  load average: 1.00, 1.05, 1.07
Tasks: 101 total,   3 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s): 25.1%us,  0.7%sy,  0.0%ni, 74.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.1%st
Mem:   8388608k total,  8334844k used,    53764k free,     9800k buffers
Swap: 12550136k total,      488k used, 12549648k free,  4936168k cached
 PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7086 appmon    18   0 13256 7880  440 R 96.7  0.1 791:16.83 bzip2
7085  appmon    18   0 19452 1148  856 S  0.0  0.0   1:45.41 tar cjvf /nwk_storelogs/compressed_logs/compressed_logs_2016_30_04.tar.bz2 /nwk_storelogs/temp/ASPEN-GC-32459:nkp-aspn-1014.log /nwk_stor
30756 appmon    15   0 85952 1944 1000 S  0.0  0.0   0:00.00 sshd: appmon@pts/0
30757 appmon    15   0 64884 1816 1032 S  0.0  0.0   0:00.01 -tcsh
shell-scripttarbzip2optimization
16
anu

最初のステップは、ボトルネックが何であるかを理解することです。それは、ディスクI/O、ネットワークI/O、またはCPUですか。

ボトルネックがディスクI/Oである場合、実行できることはあまりありません。パフォーマンスが低下するだけなので、ディスクが多くの並列リクエストを処理しないようにしてください。

ボトルネックがネットワークI/Oの場合は、ファイルが格納されているマシンで圧縮プロセスを実行します。CPUがボトルネックの場合にのみ、CPUがより高いマシンで圧縮プロセスを実行すると効果があります。

ボトルネックがCPUである場合、最初に考慮すべきことは、より高速な圧縮アルゴリズムを使用することです。 Bzip2は必ずしも悪い選択ではありません。主な弱点は解凍速度です。ただし、gzipを使用して圧縮速度をいくらか犠牲にするか、lzopやlzmaなどの他の形式を試すことができます。また、圧縮レベルを調整することもできます。bzip2のデフォルトは-9です（最大ブロックサイズなので、最大圧縮ですが、圧縮時間が最も長くなります）。環境変数BZIP2を-3のような値に設定して、圧縮レベル3を試します。 このスレッド および このスレッド 一般的な圧縮アルゴリズムについて説明します。特に このブログ投稿 derobertが引用したベンチマークでは、gzip -9またはbzip2のレベルが低いと、bzip2 -9に比べて妥協案になる可能性があると示唆されています。 この他のベンチマーク lzma（7Zipのアルゴリズムなので、7zの代わりにtar --lzmaを使用する可能性があります）も含まれます。低レベルのlzma bzip2圧縮率に速く到達します。 bzip2以外のほぼすべての選択は、解凍時間を改善します。圧縮率はデータに依存し、圧縮速度は圧縮プログラムのバージョン、コンパイル方法、および実行されたCPUに依存することに注意してください。

ボトルネックがCPUであり、複数のコアがある場合の別のオプションは、圧縮を並列化することです。それには2つの方法があります。任意の圧縮アルゴリズムで機能するのは、ファイルを個別に（個別に、またはいくつかのグループで）圧縮し、 parallel を使用してアーカイブ/圧縮コマンドを並列に実行することです。これにより、圧縮率は低下する可能性がありますが、個々のファイルの取得速度が向上し、あらゆるツールで機能します。もう1つの方法は、圧縮ツールの並列実装を使用することです。 このスレッド はいくつかをリストします。

25
Gilles 'SO- stop being evil'

pigz、並列gzipをインストールし、マルチスレッド圧縮でtarを使用できます。お気に入り：

tar -I pigz -cf file.tar.gz *

どこ -Iオプションは次のとおりです。

-I, --use-compress-program PROG
  filter through PROG

もちろん、もしあなたのNASが複数のコア/強力なCPUを持っていないなら、とにかくCPUパワーによって制限されます。

VMおよび圧縮が実行されているハードディスク/アレイの速度もボトルネックになる可能性があります。

16
mazs

データを圧縮する最も高速で効果的な方法は、生成するデータを少なくすることです。

どのような種類のログを生成していますか？ 1日の200 GBはかなり聞こえます（GoogleやISPを除いて...）。1 MBのテキストは約500ページであることを考慮して、1日あたり1億ページのテキストに相当するものを生成すると、一週間で議会の図書館を埋めます。

何らかの方法でそれを減らしても、ログから必要なものを取得できる場合は、ログデータを確認します。たとえば、ログレベルを下げるか、terserログ形式を使用します。または、統計にログを使用している場合は、統計をオンザフライで処理し、要約を含むファイルをダンプしてから、圧縮してストレージに保存する前にログをフィルタリングします。

8
Emily L.

圧縮量を削減して（節約されたスペースの観点から）、高速化できます。まず、bzip2はgzipよりもはるかに低速ですが、圧縮は小さくなります。また、bzip2、gzip、またはほとんどの圧縮プログラムの圧縮レベルを変更して、速度とサイズを交換することもできます。

速度のサイズを交換するつもりがない場合でも、LZMAを使用するコンプレッサー（xzなど）を使用して速度を改善しながら、おそらく同じサイズまたはそれよりも小さいサイズを取得できます。

検索するとベンチマークが見つかりますが、最善の策は、ターゲットハードウェアの独自のファイルを使用していくつかのテストを行うことです。

3
EricS

圧縮が高速であることが唯一の要件である場合、私は lz4 を非常に強くお勧めします。

これは、圧縮率よりも圧縮の速度が重要な多くの場所で使用されます（例：ZFSのような透過的な圧縮を備えたファイルシステム）

3
pdo