我有一台 Linux 机器,用作文件服务器。我有一个每月一次的 cron 任务,将数据驱动器的内容打包,然后通过 scp 将其复制到另一台机器以进行安全保存。生成的 tarball 大小约为 300GB,通常需要大约一天半的时间才能完成复制(通过 802.11g Wi-Fi 连接)。
今天我发现我的备份作业尚未完成,而且已经运行了 3 天。检查目标机器后,我发现到目前为止只复制了大约三分之一的数据,而且数据的增长速度似乎低于 300KB/秒。
在两台机器之间使用iperf
,我可以看到我的网络吞吐量约为 20Mbits/秒,这与我对 802.11g 连接的预期大致相同。
dd if=srcfile of=/dev/null
在源机器上使用,我可以从源驱动器(外部 USB 驱动器)读取大约 45MB/秒。
dd if=/dev/zero of=/destdrive/tmp.dat
在目标机器上使用,我可以以每秒约 30MB 的速度将数据写入目标驱动器(内置 SATA 驱动器)。对于 SATA 驱动器来说,这似乎有点慢,但也不是慢到离谱的程度(当然也不是慢到每秒 300KB)。
所以我似乎排除了两端的网络吞吐量和驱动器吞吐量,那么我还可以在哪里找到瓶颈的根源呢?
答案1
scp
为什么首先要使用它来复制大文件?scp
有其自己的开销(加密,真实性检查等)。
您可以使用rsync
(rsync 非常适合通过 ssh 传输大文件,因为它能够继续由于某种原因而中断的传输。由于它使用哈希函数来检测相等的文件块,因此继续功能非常强大。)或其他工具。
请参阅此帖子。通过网络复制大文件,速度更快
如果您无论如何都想使用 scp ,那么您应该使用traceroute
和tcpdump
来iftop
查看从源到目标的数据包。您可能会发现一些不寻常的东西。
答案2
检查以确保未启用 -l 选项来限制带宽。此外,似乎有一个 -v 可以洞察下一次运行的情况。
详细模式。使 scp 和 ssh(1) 打印有关其进度的调试消息。这有助于调试连接、身份验证和配置问题。
这个问题之前已经回答过了。引用自答案。
scp 使用交互式终端来打印那个漂亮的进度条。将该输出打印到文件根本没有意义,因此 scp 会检测其输出何时重定向到终端以外的其他地方并禁用此输出。
完整答案
https://stackoverflow.com/questions/3890809/bash-stdout-redirect-of-commands-like-scp
SCP 手册页
答案3
我在复制文件时也遇到了 SCP 性能缓慢的问题,速度约为 150-300KiB/s,而不是 10MiB/s。我还注意到,当我复制文件时,目标服务器上的 1 个 CPU 核心处于 100% 繁忙状态。我谷歌了一下,发现提议:在 SCP 连接选项中禁用“优化连接缓冲区大小”。这很有帮助。禁用此选项后,速度提高到预期的网络水平,服务器上的 CPU 负载显著减少。