我有一台 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 负载显著减少。