我们在 Linux 计算机上有 100+ GB 的文件，在尝试使用以下命令执行 gzip 时，gzip 至少需要 1-2 小时才能完成：
gzip file.txt
有没有一种方法可以让 gzip 快速运行，并且与使用 gzip 时的压缩级别相同？
CPU：Intel(R) Core(TM) i3-2350M CPU @2.30 GHz
答案1
如果您使用 gzip，则主要使用一个处理器核心（嗯，任务的某些部分，例如读取和写入数据是内核任务，而内核将使用另一个核心）。看看一些支持多核的 gzip 替代品，例如 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
我们有 100+ GB 文件，在尝试使用以下命令执行 gzip 时，gzip 至少需要 1-2 小时才能完成
使用 CPU（摘自评论）：英特尔® 酷睿™ i3-2350M @ 2.30GHz， 其中有：
核心数量：2；线程数：4
根据以下数据，您的 CPU 听起来像是瓶颈这么低的分数（基准测试），还要注意这是一款笔记本电脑 CPU，相当旧了。在此设置中，我期望使用经典 HDD，而不是一些现代 SSD，以及可能较低的 RAM 等。
gzip结论可能是否定的，当然，如果不降低压缩比，您就无法在软件方面做任何事情来获得计算机上的更高性能。
-6如果我没记错的话，默认压缩设置是，例如你可以打-2:
gzip -2 file.txt
并自己比较结果。请参阅手册页了解更多设置。
更新于pigz
今天，2021 年 6 月 3 日，我自己需要压缩一个相当大的文件，大小为 256 GB（239吉布），我进行了一些测试，，，，gzip我发现所有这些都无法充分利用我的CPU（bzip2xzi7-7700HQ）和快速，这是我们本次问答的目标。
最后我下载了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使用p阿拉雷尔我的实施广州ip，对于非常大的文件。
答案3
您是否特别需要 gzip，或者可以选择其他压缩算法吗？ zstandard 和 lzop 都比 gzip 快得多。
答案4
您的瓶颈是：它读取文件的速度有多快，压缩文件的速度有多快，以及写入文件或将其传输到目标介质（可能通过网络）的速度有多快。
首先要做的就是运行 gzip 命令，同时监视输出
vmstat 1
在另一个终端。您将看到您的 CPU 是否已达到极限、使用了多少个核心以及读取和写入的 MB/秒数。复制大文件时还要监视 vmstat，以了解硬盘驱动器的最大读/写速度。然后您就会知道该操作是 cpu 限制还是 io 限制。
您还可以使用
time gzip ...
它会告诉您它使用了多少 cpu 时间与总时间，以便提供关于它是否受 cpu 限制或等待 IO 的有用提示。
如果您打算将压缩文件传输到另一个硬盘或通过网络，那么在压缩文件时这样做是有意义的，而不是使用单独的复制操作。如果目标驱动器是本地驱动器，则只需使用适当的 gzip 语法即可；如果是远程的，您可以使用网络共享或：
gzip -c file.txt | ssh user@ip "cat > destfile.gz"
这将对文件进行 gzip 压缩并通过一个管道操作进行传输，这比两个单独的步骤更快。
现在，观察 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。您还可以使用更快的压缩设置，因为节省几 GB 的硬盘空间可能比节省几个小时重要得多。
如果压缩文件的大小不如压缩所需的时间重要，则最佳解决方案是压缩速度足够快，以饱和磁盘或网络瓶颈。
例如，如果您的网络速度较慢，磁盘速度较快，并且您有空闲的 CPU，则使用较高的压缩设置将通过传输较少量的压缩数据来使其速度更快。但如果您的网络速度较快而 CPU 较慢，则较低的压缩设置将使用较少的 CPU，因此速度会更快。
那么，这个 100GB 的文件从哪里来呢？这不是常见的文件大小...它暗示您确实应该在增量模式下使用 rsync。