☰

为什么 NFS 复制速度是 SSH scp 的一半？

tag-icon • tag-icon rhel scp file-copy nfsv4
为什么 NFS 复制速度是 SSH scp 的一半？
  • RHEL 7.9 x86-64
  • 配备 Xeon cpu、512GB RAM、intel 网卡的高端戴尔服务器
  • 我是服务器上的唯一用户，并且他们没有其他工作负载
  • 思科1Gbps 有线局域网
  • 数据.tar约为 50 GB
  • /bkupNFS 是否安装为 vers=4.1 并同步
  • ascp data.tar backupserver:/bkup/运行于112MB/秒始终如一；我已经看到这个 5 年多了并且相信这是正确的
  • arsync -P data.tar /bkup运行于55MB/秒始终如一；这个正在通过 NFS 进行复制
  • 同时运行两个副本，scp 从 112 下降到 55，通过 NFS 的 rsync 从 55 下降到 35
    • 当一个复制完成后，另一个复制速度恢复到原始速度

为什么？如何提高 NFS 的速度？

答案1

主要原因可能是使用该sync选项挂载了 NFS 共享。理论上，这可以提高服务器可能突然消失或客户端可能意外断开连接的情况下的数据安全性，但也会损害性能。

使用syncmount 选项相当于应用程序fsync()在每次调用write(). IOW，每次客户端提交 IO 请求时，都必须等待该请求完成才能提交另一个请求。即使与以下命令一起使用，这也会对数据写入速度产生不小的影响：当地的文件系统，但网络文件系统可以做到这一点很多更糟糕（因为在每个 IO 请求之后至少需要一次完整的网络往返才能发出下一个请求）。如果您有时间，您可以通过尝试使用 TFTP（与 SCP 相比）复制一个几百 MB 大小的文件来亲自体验这种效果。 TFTP 在基本级别上将这种类型的同步融入到协议中，并以以下方式实现：在发送下一个数据包之前，必须确认每个单独的数据包，因此其性能可能会比 NFS 所看到的还要低。

如果您使用的是能够自动替换文件并正常处理副本的负责任的软件，您可以安全地切换到asyncNFS 模式以避免此问题。

相关内容