我正在运行以下命令将 LVM 从一台主机复制到另一台主机：
dd if=/dev/vg_1/lv1 conv=noerror,sync bs=4M | gzip | ssh user@ip 'gzip -d | dd of=/dev/vg_2/lv1 bs=4M'
首先，大约一个小时前，我的速度约为 11 MB/s。随着时间的流逝，传输速率已增至约 34.4 MB/s，并且仍在以恒定速率增长。
我很想知道为什么。
我最好的猜测是我正在复制的 LVM 非常大，但实际上只有一小部分是数据。结果可能是大块的数据被 0 填充。这会使 gzip 压缩更有效吗？
您可以通过省略这两个gzip命令来简化您的命令。如果压缩在您的情况下很有用，那么通过为命令提供-C参数来压缩传输中的数据要简单得多ssh，而且也不太容易出错，因为您不会意外地在一端而不是另一端使用 gzip。
为了回答您的原始问题，并确定压缩是否提高了吞吐量，您首先需要找出瓶颈在哪里。
瓶颈有五个候选者：
查看每台计算机上的顶部，您应该能够看到是否存在与花费接近 100% CPU 时间的传输相关的进程。如果是这种情况，这肯定表明该计算机上的 CPU 是瓶颈。
如果 OTOH 您在任一端看到 dd 命令花费大量时间处于D状态（意味着不可中断的睡眠），则表明该计算机上的 I/O 是瓶颈。
要确定网络是否是瓶颈，请查看netstat输出。如果网络是瓶颈，您应该在源端看到大的发送队列，在目标端看到空的接收队列。
如果发送队列和接收队列都很大，说明瓶颈在目的地。如果两者都为空，则表明瓶颈在源上。
如果未经压缩的副本最终在网络连接上出现瓶颈，则压缩可能会提高性能。如果瓶颈在其他地方，压缩不太可能有帮助。如果 CPU 时间花费在加密和解密数据上首先是瓶颈，那么压缩可能会损害性能，除非数据非常冗余并获得高压缩率。
由于多种原因，吞吐量可能会随着时间的推移而发生变化，这可能会导致瓶颈的位置在您尝试定位时发生变化。由于压缩比的变化，压缩可能会导致吞吐量的更多变化，这是对您所看到的最可能的解释。
但吞吐量可能因许多其他原因而异，包括：