我正在运行以下命令将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' 一开始我在一个小时前得到了大约11MB / s的速度。 随着时间的推移，传输速率已经达到了34.4 MB / s，并且仍在以不变的速度增长。
我很好奇，知道为什么。
我最好的猜测是，我正在复制的LVM非常大，但实际上只有一小部分是数据。 结果可能是大块的数据填充为0.这会使gzip压缩效率更高吗？
省略两个gzip命令可以简化您的命令。 如果压缩在你的情况下是有用的，通过给ssh命令提供一个-C参数来压缩传输数据就简单多了，而且它也不太容易出错，因为你不会在一端意外地使用gzip而不是另一端。
为了回答你原来的问题，为了说压缩是否提高了吞吐量，你首先需要找出瓶颈在哪里。
有五个候选人的瓶颈：
在每台计算机上查看顶部，您应该能够看到是否有与转移支出接近100％的CPU时间相关的过程。 如果是这样的话，那么计算机上的CPU就是瓶颈。
如果OTOH在任何一端都看到dd命令在D状态下花费大量时间（意味着不可中断的睡眠），则表明该计算机上的I / O是瓶颈。
要了解networking是否是瓶颈，请查看netstat输出。 如果networking是瓶颈，则应在源端看到大的发送队列，并在目的地看到空的接收队列。
如果发送队列和接收队列都很大，则表明瓶颈在目的地。 如果两者都是空的，则表明瓶颈在源头上。
如果没有压缩的副本在networking连接上遇到瓶颈，那么压缩可能会提高性能。 如果瓶颈是其他地方，压缩不太可能帮助。 如果CPU时间花在encryption和解密数据上是瓶颈，压缩可能会损害性能，除非数据非常冗余，并获得高压缩比。
由于多种原因，吞吐量可能随时间而变化，这可能会导致瓶颈的位置在您尝试查找时发生变化。 由于压缩比的变化，压缩可能会导致吞吐量变化更大，这是您所看到的最可能的解释。
但吞吐量可能会有很多其他的原因，包括：