我正在运行以下命令将 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 压缩更有效吗？
答案1
可以通过省略这两个gzip命令来简化您的命令。如果压缩在您的案例中很有用，那么通过-C为命令提供参数来压缩传输中的数据要简单得多ssh，而且出错的可能性也更小，因为您不会意外地在一端使用 gzip 而在另一端不使用。
为了回答您最初的问题，并且为了说明压缩是否提高了吞吐量，您首先需要找出瓶颈在哪里。
瓶颈有五个候选点：
- 源上的 I/O
- 源上的 CPU
- 网络吞吐量
- 目标上的 CPU
- 目标上的 I/O
查看每台计算机上的 top，您应该能够看到是否有与传输相关的进程花费了接近 100% 的 CPU 时间。如果是这种情况，则肯定表明该计算机上的 CPU 是瓶颈。
另一方面，如果您看到任一端的 dd 命令花费大量时间处于D状态（意味着不可中断的睡眠），则表明该计算机上的 I/O 是瓶颈。
要确定网络是否是瓶颈，请查看netstat输出。如果网络是瓶颈，您应该看到源上的发送队列很大，而目标上的接收队列为空。
如果发送队列和接收队列都很大，则表明瓶颈在目标上。如果两者都为空，则表明瓶颈在源上。
如果未压缩的副本最终导致网络连接出现瓶颈，则压缩可能会提高性能。如果瓶颈在其他地方，则压缩不太可能有帮助。如果加密和解密数据所花费的 CPU 时间首先是瓶颈，则压缩可能会损害性能，除非数据非常冗余并且压缩率很高。
由于多种原因，吞吐量会随时间而变化，这可能会导致瓶颈位置在您尝试定位时发生变化。压缩可能会导致吞吐量发生更多变化，因为压缩率会发生变化，这是您所看到的情况最有可能的解释。
但吞吐量可能会因许多其他原因而发生变化，包括：
- 底层媒体的碎片化
- 介质上的坏扇区减慢了数据传输速度
- 介质的物理特性导致吞吐量随介质上的位置而变化。
- 其他不相关进程导致的计算机负载
- 可用网络容量的变化