Linuxシステムには100 GB以上のファイルがあり、次のコマンドを使用してgzipを試みると、gzipを完了するのに少なくとも1〜2時間かかります。
gzip file.txt
gzipを使用するときと同じ圧縮レベルでgzipをすばやく実行する方法はありますか？
CPU: Intel(R) Core(TM) i3-2350M CPU @2.30GHz
答え1
gzipを使用している場合は、主に1つのプロセッサコアを使用します。データの読み書きなどの一部の操作はカーネル操作であり、カーネルは異なるコアを使用します。 MiGz（https://github.com/linkedin/migz）または豚（https://zlib.net/pigz/、詳しくは次をご覧ください。https://medium.com/ngs-sh/pigz-a-faster-alternative-to-gzip-for-big-files-d5909e46d659）。
答え2
100GB以上のファイルがあり、次のコマンドを使用してgzipを試みると、gzipを完了するのに少なくとも1〜2時間かかります。
CPUを使用する（コメントから取得）：インテル®Core™i3-2350M @ 2.30GHz、含まれて:
コア数：2;スレッド数：4
次のデータによると、CPUにボトルネックがあるようです。スコアが低すぎます。（ベンチマーク）また、これはかなり古いラップトップCPUであることに注意してください。この設定では、最新のSSDではなく、古典的なHDDとRAMが低いことを期待しています。
gzip結論はおそらく「いいえ」です。もちろん、圧縮率を下げることなくコンピュータでより高いパフォーマンスを得るためにソフトウェアでできることはありません。
-6私が正確に覚えている場合、デフォルトの圧縮設定は次のとおりです。たとえば、次のように入力できます。-2:
gzip -2 file.txt
そしてその結果を直接比較してみてください。よりマニュアルページ設定の詳細をご覧ください。
更新日pigz
2021年6月3日今日、私は256GBサイズのやや大きなファイルを圧縮する必要がありました。239 ギブス）、いくつかのテストを実行しましたがgzip、すべて私のCPUを完全に活用できないことがわかりました（bzip2xzi7-7700HQ）速く、これがこのQ&Aの目標です。
最後にダウンロードしましたpigz（マニュアルページ）何からホームページを実行し、単にコンパイルし、make私のファイルに直接置くのが好きではなかったので、PATHバイナリのBashエイリアスを作成しました。
（潜在的に長い）進行状況を観察する方法を記録しておくと便利です。
例 #1 (準備されたディスクイメージを読み込み、gzip同じディレクトリに 'ed ファイルを書き込む):
file=disk.img; pv < "$file" | pigz -2 > "$file".gz
例 #2 (ディスクから直接読み込み、gzip現在のディレクトリに 'ed ファイルを書き込む):
dev=/dev/nvme0n1; file=disk.img.gz; pv < "$dev" | pigz -9 > "$file"
結論として
今、私は以下をpigz使用することをお勧めします。血アラレル私実装広州ip、非常に大きなファイルの場合。
答え3
特にgzipが必要ですか、それとも選択できる他の圧縮アルゴリズムはありますか？ zstandardとlzopはどちらもgzipよりはるかに高速です。
答え4
ボトルネックは、ファイルを読み取る速度、ファイルを圧縮する速度、ファイルを書き込んだり、宛先メディア（おそらくネットワーク経由）に転送したりできる速度です。
最初にすべきことは、gzipコマンドを実行して出力を監視することです。
vmstat 1
他の端末から。 CPUが最大値に達したか、使用中のコア数、読み書きする1秒あたりのMB数を確認できます。また、大容量ファイルをコピーするときにvmstatを監視して、ハードドライブの最大読み取り/書き込み速度を確認します。これにより、ジョブがCPUバインディングであるかioバインディングであるかがわかります。
また、使用することができます
time gzip ...
合計時間に対して使用中のCPU時間を知らせ、CPUバインディングかIOスタンバイの有益なヒントを提供します。
圧縮ファイルを別のハードドライブまたはネットワーク経由で転送する場合は、別のコピー操作を使用するよりもファイルを圧縮しながら実行することをお勧めします。ターゲットドライブがローカルの場合は適切なgzip構文を使用し、リモートの場合はネットワーク共有を使用するか、次のことができます。
gzip -c file.txt | ssh user@ip "cat > destfile.gz"
これはファイルをgzipに圧縮し、単一のパイプ操作を介して転送し、それは別々の2つのステップよりも高速です。
ここで vmstat を観察し、ジョブが io バインディング、ネットワークバインディング、または CPU バインディングであることを確認します。 「pv」ユーティリティをインストールし、次のように使用することをお勧めします。
gzip -c file.txt | pv | ssh user@ip "cat > destfile.gz"
pvは、ネットワーク経由で送信された圧縮データのMB / s数を表示します。次のコマンドを使用して、HDD読み取り、ネットワーク、および相手の書き込みをテストできます。
cat file.txt | pv | ssh user@ip "cat > destfile.gz"
ハードドライブネットワークをテストし、もう一方の端に書き込むことができます。
cat /dev/zero | pv | ssh user@ip "cat > destfile.gz"
...次を使用してネットワークをテストできます。
cat /dev/zero | pv | ssh user@ip "cat > /dev/null"
今何があなたのスピードを遅らせるかをよりよく知っているでしょう。 Sambaネットワーク共有を使用している場合は、スループットもテストする必要があります。
cat /dev/zero | pv > /mnt/share/filename
...誤った設定がネットワーク共有のパフォーマンスを低下させる可能性があることに注意してください。
問題が実際にgzipの速度であると判断された場合、解決策はzstandardなどのより高速のマルチスレッドコンプレッサーを使用することです。数時間を節約するよりも、数ギガバイトのハードドライブ容量を節約する方が重要な場合があるため、より高速な圧縮設定を使用することもできます。
圧縮ファイルのサイズが圧縮に必要な時間よりも重要ではない場合、最善の解決策は、ディスクまたはネットワークのボトルネックを飽和させるのに十分な速さで圧縮することです。
たとえば、ネットワークが遅く、ディスクが速く、空きCPUがある場合、高い圧縮設定を使用すると、より少ない量の圧縮データを転送して速度が速くなります。ただし、ネットワークが高速でCPUが遅い場合は、圧縮設定を下げるとCPUが少なくなり、速度が速くなります。
それでは、この100GBファイルはどこから来るのでしょうか？これは一般的なファイルサイズではありません。これは実際には増分モードでrsyncを使用する必要があることを意味します。