压缩超大 (100G) 文件的时间

Flo*_*ris 42 linux gzip

我发现自己不得不压缩许多非常大的文件(80-ish GB),而且我对我的系统表现出的(缺乏)速度感到惊讶。我得到大约 500 MB/分钟的转换速度;using top,我似乎以大约 100% 的速度使用单个 CPU。

我很确定这不是(只是)磁盘访问速度,因为创建一个tar文件(这就是创建 80G 文件的方式)只花了几分钟(可能是 5 或 10 分钟),但是 2 个多小时后,我的简单 gzip 命令仍然存在尚未完成。

总之:

tar -cvf myStuff.tar myDir/*
Run Code Online (Sandbox Code Playgroud)

创建一个 87 G 的 tar 文件花费了 <5 分钟

gzip myStuff.tar
Run Code Online (Sandbox Code Playgroud)

花了 2 小时 10 分钟,创建了一个 55G 的 zip 文件。

我的问题:这正常吗?是否有某些选项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
Run Code Online (Sandbox Code Playgroud)

所以是的,将标志从默认-6更改为最快可以-1使我的速度提高 30%,(对于我的数据)zip 文件的大小几乎没有任何变化。无论我使用的是同一个磁盘还是另一个磁盘,本质上都没有区别(我必须多次运行它才能获得任何统计意义)。

如果有人感兴趣,我使用以下两个脚本生成了这些计时基准:

#!/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
Run Code Online (Sandbox Code Playgroud)

第二个脚本 ( 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
Run Code Online (Sandbox Code Playgroud)

需要注意的三件事:

  1. 使用/usr/bin/time而不是time,因为 的内置命令的bash选项比 GNU 命令少得多
  2. 我没有打扰使用该--format选项,尽管这会使日志文件更易于阅读
  3. 我使用了一个脚本中的脚本,因为它time似乎只对管道序列中的第一个命令进行操作(所以我让它看起来像一个单一的命令......)。

有了这些知识,我的结论是

  1. -1标志加快速度(接受的答案)
  2. 比从磁盘读取更多的时间花在压缩数据上
  3. 投资更快的压缩软件(pigz似乎是一个不错的选择)。
  4. 如果您有多个文件要压缩,您可以将每个gzip命令放在自己的线程中并使用更多可用的 CPU(穷人的pigz

感谢所有帮助我学习这一切的人!

rob*_*rod 37

您可以使用--fast --best或更改 gzip 的速度,-#其中 # 是 1 到 9 之间的数字(1 是最快但压缩较少,9 是最慢但压缩较多)。默认情况下 gzip 在级别 6 运行。


小智 36

与 gzip 相比,tar 花费的时间如此之少的原因是将文件复制到单个文件(这就是它所做的)时的计算开销非常小。另一方面,gzip 实际上是使用压缩算法来缩小 tar 文件。

问题是 gzip 被限制为(如您所发现的)单个线程。

输入pigz,它可以使用多个线程来执行压缩。如何使用它的一个例子是:

tar -c --use-compress-program=pigz -f tar.file dir_to_zip
Run Code Online (Sandbox Code Playgroud)

姊妹站点有一个关于 --use-compress-program 选项的简洁摘要。

  • 这是这里的正确答案..! (2认同)

Dav*_*ett 5

我似乎以大约 100% 的速度使用单个 CPU。

这意味着不存在 I/O 性能问题,但压缩仅使用一个线程(gzip 就是这种情况)。

如果您设法获得安装其他工具所需的访问/协议,那么 7zip 还支持多线程以利用多核 CPU,尽管我不确定这是否扩展到 gzip 格式以及它自己的格式。

如果您暂时只能使用 gzip 并且有多个文件需要压缩,您可以尝试单独压缩它们 - 这样您就可以通过并行运行多个进程来使用更多的多核 CPU。但请注意不要过度使用,因为一旦接近 I/O 子系统的容量,性能就会急剧下降(低于使用一个进程/线程的情况),因为头部移动的延迟变得非常显着。瓶颈。