☰

如何找到通过 WAN 传输文件的瓶颈

tag-icon • tag-icon ssh performance rsync
如何找到通过 WAN 传输文件的瓶颈

这个问题可能有点太宽泛了，但我正在寻找一些方法来识别传输速度瓶颈。我使用 rsync 在位于不同位置的 2 个 NAS 设备（具体来说是 DNS-323）之间传输文件。我通过 SSH 建立隧道。根据 rsync，传输速率平均为 320-370kB/s。

我知道这里有很多变量，所以我想知道我应该采取什么流程来确定传输速度如此缓慢的原因。以下是一些相关细节。

  • NAS 的互联网上传速度约为 3.5Mbps
  • NAS 的互联网下载速度约为 20Mbps
  • 两个 NAS 在传输过程中的CPU 使用率（根据top）约为 40-45%
  • 两个 NAS 上的 rsync 进程的内存使用量（根据top）约为 160-190%（不确定这意味着什么）
  • 我使用 AES 密码
  • 我正在使用 OpenSSHHPN 补丁在两个 NAS 上

我最初的假设是，由于这些设备的 CPU 较弱，加密开销是瓶颈。但如果是这样的话，难道我不应该看到更高的 CPU 使用率吗？两台机器上的 ssh 进程仅显示约 15% 的 CPU 使用率。

我的下一个想法是 HDD I/O 传输速度限制了一些东西，但是 NAS 在进行本地传输时能够以更快的速度读取/写入，所以不可能是这个原因。

还有什么原因导致传输缓慢？有什么科学方法可以确定瓶颈是什么吗？

答案1

我把这整件事都打出来了，然后我意识到答案非常明显。我没有直接删除它，而是决定分享这个答案，以防其他人也遇到同样的情况。

3.5Mb/秒 = 448KB/秒

因此，我的上行链路饱和度达到 70-80%。考虑到网络上其他计算机的流量、TCP 开销、数据包丢失等，我认为我看到的传输速度实际上相当不错。如果有人不同意或发现提高性能的方法，我仍然很乐意听取。

相关内容