![随着 dd 的进展,dd 命令通过 gzip 和 ssh 传输的速度越来越快](https://linux22.com/image/631451/%E9%9A%8F%E7%9D%80%20dd%20%E7%9A%84%E8%BF%9B%E5%B1%95%EF%BC%8Cdd%20%E5%91%BD%E4%BB%A4%E9%80%9A%E8%BF%87%20gzip%20%E5%92%8C%20ssh%20%E4%BC%A0%E8%BE%93%E7%9A%84%E9%80%9F%E5%BA%A6%E8%B6%8A%E6%9D%A5%E8%B6%8A%E5%BF%AB.png)
我正在运行以下命令将 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 时间首先是瓶颈,则压缩可能会损害性能,除非数据非常冗余并且压缩率很高。
由于多种原因,吞吐量会随时间而变化,这可能会导致瓶颈位置在您尝试定位时发生变化。压缩可能会导致吞吐量发生更多变化,因为压缩率会发生变化,这是您所看到的情况最有可能的解释。
但吞吐量可能会因许多其他原因而发生变化,包括:
- 底层媒体的碎片化
- 介质上的坏扇区减慢了数据传输速度
- 介质的物理特性导致吞吐量随介质上的位置而变化。
- 其他不相关进程导致的计算机负载
- 可用网络容量的变化