非常に大きな（100G）ファイルを圧縮する時間

多数の非常に大きなファイル（80ギガバイトのGB）を圧縮しなければならないことに気づき、システムの速度（不足）に驚いています。約500 MB /分の変換速度が得られます。を使用してtop、私は単一のCPUを約100％使用しているようです。

tarファイルの作成（80Gファイルの作成方法）には数分（おそらく5または10）しかかからなかったため、（ちょうど）ディスクアクセス速度ではないと確信していますが、2時間以上たっても私の単純なgzipコマンドはまだですまだ完成してない。

要約すれば：

tar -cvf myStuff.tar myDir/*

87 Gのtarファイルを作成するのに5分未満かかりました

gzip myStuff.tar

55G zipファイルを作成して、2時間10分かかりました。

私の質問：これは正常ですか？gzip物事をスピードアップするための特定のオプションはありますか？コマンドを連結して使用する方が速いでしょうtar -cvfzか？私はへの参照を見たpigz- のgzipの並列実装をのでそれは私のためのオプションではありませんが、残念ながら私は私が使用しているマシンにソフトウェアをインストールすることはできません- 。たとえば、この前の質問を参照してください。

私はこれらのオプションのいくつかを自分で試して時間を計ります-しかし、オプションの「魔法の組み合わせ」に当たらない可能性が高いです。このサイトの誰かが物事をスピードアップするための正しいトリックを知っていることを望んでいます。

他のトライアルの結果が利用可能になったら、この質問を更新します-しかし、誰かが特に良いトリックを利用できるなら、本当に感謝します。おそらくgzipの処理時間は、私が思っていたよりも長くなります...

更新

約束されたように、圧縮の量を変更し、ファイルの宛先を変更するという、以下に提案するトリックを試しました。約4.1GBのtarに対して次の結果が得られました。

flag    user      system   size    sameDisk
-1     189.77s    13.64s  2.786G     +7.2s 
-2     197.20s    12.88s  2.776G     +3.4s
-3     207.03s    10.49s  2.739G     +1.2s
-4     223.28s    13.73s  2.735G     +0.9s
-5     237.79s     9.28s  2.704G     -0.4s
-6     271.69s    14.56s  2.700G     +1.4s
-7     307.70s    10.97s  2.699G     +0.9s
-8     528.66s    10.51s  2.698G     -6.3s
-9     722.61s    12.24s  2.698G     -4.0s

そのため、フラグをデフォルト-6から最速に変更すると-1、30％の速度向上が得られ、zipファイルのサイズは（データに対して）ほとんど変更されません。同じディスクを使用していても、別のディスクを使用していても本質的に違いはありません（統計的有意性を得るには、これを複数回実行する必要があります）。

興味のある方は、次の2つのスクリプトを使用してこれらのタイミングベンチマークを生成しました。

#!/bin/bash
# compare compression speeds with different options
sameDisk='./'
otherDisk='/tmp/'
sourceDir='/dirToCompress'
logFile='./timerOutput'
rm $logFile

for i in {1..9}
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $sameDisk $logFile
  do  /usr/bin/time -a --output=timerOutput ./compressWith $sourceDir $i $otherDisk $logFile
done

2番目のスクリプト（compressWith）：

#!/bin/bash
# use: compressWith sourceDir compressionFlag destinationDisk logFile
echo "compressing $1 to $3 with setting $2" >> $4
tar -c $1 | gzip -$2 > $3test-$2.tar.gz

注意すべき3つのこと：

1. ので/usr/bin/timeはなくを使用するのはtime、組み込みコマンドのbashオプションがGNUコマンドよりもはるかに少ないためです
2. この--formatオプションを使用することはありませんが、ログファイルが読みやすくなります
3. timeパイプシーケンスの最初のコマンドでのみ動作するように思われるので、スクリプトインスクリプトを使用しました（したがって、1つのコマンドのように見えました...）。

このすべてを学んだので、私の結論は

1. -1フラグを使用して物事をスピードアップします（受け入れられた回答）
2. ディスクから読み取るよりもはるかに多くの時間がデータの圧縮に費やされます
3. より高速な圧縮ソフトウェアに投資します（pigz良い選択のようです）。
4. 圧縮するファイルが複数ある場合は、各gzipコマンドを独自のスレッドに入れて、使用可能なCPUをより多く使用できます（貧乏人pigz）

このすべてを学ぶのを手伝ってくれたみんなに感謝します！

--fast --bestまたはを使用してgzipの速度を変更できます-#。＃は1〜9の数値です（1は最速ですが圧縮率が低く、9は最も低速ですが圧縮率が高くなります）。デフォルトでは、gzipはレベル6で実行されます。

tarがgzipに比べて時間がかからない理由は、ファイルを単一のファイルにコピーする際の計算オーバーヘッドが非常に少ないためです（これが行うことです）。一方、gzipは、圧縮アルゴリズムを使用してtarファイルを圧縮しています。

問題は、gzipが（発見したように）単一スレッドに制限されていることです。

pigzと入力します。これは、複数のスレッドを使用して圧縮を実行できます。これの使用方法の例は次のとおりです。

tar -c --use-compress-program=pigz -f tar.file dir_to_zip

姉妹サイトに --use-compress-programオプションの簡潔な要約があります。

単一のCPUを約100％使用しているようです。

これは、I / Oパフォーマンスの問題はないことを意味しますが、圧縮には1つのスレッドしか使用されていません（gzipの場合）。

他のツールをインストールするために必要なアクセス/合意を達成することができた場合、7zipはマルチスレッドをサポートしてマルチコアCPUを活用しますが、それがgzip形式だけでなく独自のものにも拡張されるかどうかはわかりません。

とりあえずgzipだけを使用していて、圧縮する複数のファイルがある場合は、それらを個別に圧縮してみてください-複数のプロセスを並行して実行することにより、そのマルチコアCPUをより多く使用できます。ただし、I / Oサブシステムの能力に近いところに到達するとすぐに、頭の動きの待ち時間が大きくなるにつれて（1つのプロセス/スレッドを使用している場合よりも低く）パフォーマンスが急激に低下するため、無理をしないように注意してくださいボトルネック。

pigzで利用可能なプロセスの数を活用することもできます。これは、通常、次のコマンドに示すようにパフォーマンスが高速です。

tar cf-アーカイブするディレクトリ| pigz -0 -p largenumber> mydir.tar.gz

例-tar cf-patha | pigz -0 -p 32> patha.tar.gz

-pは実行可能なプロセスの数であるため、これはおそらく投稿で提案されている方法よりも高速です。私の個人的な経験では、アーカイブするディレクトリが多数の小さなファイルで構成されている場合、非常に大きな値を設定してもパフォーマンスは低下しません。それ以外の場合、考慮されるデフォルト値は8です。大きなファイルの場合、システムでサポートされるスレッドの総数としてこの値を設定することをお勧めします。

32 CPUマシンの場合にp = 32の値を設定する例が役立ちます。

0は、アーカイブを圧縮せず、速度に焦点を合わせているため、最も速いpigz圧縮を意味します。圧縮のデフォルト値は6です。