☰

高延迟下的 NFS 性能很差，ssh 上的 rsync 大约快 100 倍

tag-icon • tag-icon rsync nfsv4
高延迟下的 NFS 性能很差，ssh 上的 rsync 大约快 100 倍

我们使用 rsync 来同步两个 NFS 服务器的数据。一台 NFS 服务器位于东海岸，另一台位于西海岸。 RTT约为110ms。

在东海岸 NFS 服务器上，我安装了西海岸 NFS 服务器安装点。

<server>:/home/backups on /mnt/backups type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)。

数据已经在两台服务器上，只是为了验证数据（例如同步文件夹以及何时不需要更改）。以下是验证 7GB 文件夹的东海岸服务器与西海岸服务器相同所需的时间。

以下大约需要8分钟才能完成超过7GB的数据。

rsync -r -vvvv --info=progress2 --size-only /<local_path>/ /<remote_path>/

以下（避免使用NFS挂载）大约需要15秒才能完成超过7GB的数据（同上）。

rsync -r -vvvv --info=progress2 --size-only /<local_path>/ <user>@<west_cost_NFS>:/<remote_path>/

同样，上面的内容不会移动任何数据，因为文件夹已经同步，它只是验证数据是否相同（基于文件的大小）。

我尝试-o async在客户端和服务器上使用，但当我在客户端上运行“mount”时，/etc/exports async客户端永远不会显示。async我认为async是默认的。我尝试过将 rsize、wsize 也更改为更大的值，但性能并没有变得更好。我是否完全可以从 NFS 中获得更好的性能？

答案1

在我看来，你试图使用 rsync 是错误的。 Rsync 的协议专为比较/同步两个独立服务器上的大型文件系统的确切场景而设计。它尽可能地在本地执行两个都在中间比较之前本地和远程机器。

其协议的设计使得一台机器上的 rsync 代理与另一台机器上的 rsync 代理进行通信，并且该协议旨在大幅减少完成任务所需的往返次数（和总数据）。

rsync 的设计目的是：

            [fast]        [slow SSH]        [fast]
File system <----> rsync <----------> rsync <----> File system

Rsync 针对两个代理之间的网络性能进行了优化，但它无法控制用于访问磁盘的协议。因此，当您挂载远程 NFS 文件系统时，您会更改网络访问配置文件：

            [fast]        [fast]        [slow NFS]
File system <----> rsync <------> rsync <---------> File system

Rsync 对此无能为力，因为它完全无法控制 NFS 协议。

这里的一个具体区别是，通过 NFS，每个文件都必须是单独地请求。要探索包含的文件树，/foo/bar/baz您必须请求/[等待] 然后请求/foo[等待] 然后请求/foo/bar[等待] 然后最后请求/foo/bar/baz。每个请求的延迟为 110ms，即延迟为 330ms，并且您只能获得一个文件。

代理之间的 Rsync 协议没有此限制。在远程计算机上运行的代理会急切地编译远程文件系统中正在同步的每个文件和目录的列表，并发送所有内容。对于整个文件树只有一个请求！

看rsync 是如何工作的

答案2

你的前提是错误的。当您通过 NFS 执行文件系统比较时，您将移动大量数据 - 有关文件的元数据。对于一棵大树来说，有很多单独的请求，每个请求都有延迟。

当您通过 SSH 连接使用 rsync 时，您将发送文件名和元数据流供远程端进行验证。它可能是相同数量的文件，因此具有相同数量的元数据，但它是流式传输的，因此总体延迟非常低。

对于 110 毫秒的 RTT，您很容易就会得到 15 秒而不是 8 分钟。

哦，当您开始使用时，请将标志rsync替换-r为-a（理想）或-rt（足够）。除非包含文件时间戳，否则rsync最终会认为连接两端的文件相对于彼此已过期。

答案3

当前（2023 年 2 月）使用 RHEL 8.7 之前一直在使用 RHEL 7.9，我可以告诉您，在 RHEL 7.9 中我永远无法让 NFS vers=4.2 工作。 vers=4.1 时它会达到最大值。并且只有当我没有从原始安装状态修改/etc/nfs/nfs.conf或文件时。/etc/sysconfig/nfs

这篇文章提到对 NFSv4 和 NFSv4.1 的一些评论表明，这些版本的带宽和可扩展性有限，并且 NFS 在网络流量较大时会变慢。据报道，NFSv4.2 改善了带宽和可扩展性问题。最后更新于 2022 年 4 月。

https://www.techtarget.com/searchenterprisedesktop/definition/Network-File-System

我最近也问过这个问题

是否有理由使用 NFS 3 而不是 4.2 版本？

所以在我看来根据我最近玩 NFS 的经历，除非你能得到vers=4.2并proto=rdma使用它或许使用 nfs v3 作为 UDP 可能会提供最佳性能。特别是async在/etc/exportfsnfs 服务器上指定。你是对的，你不会看到异步在 nfs 客户端作为挂载选项提到；我对此进行了测试，并观察到立即使用rsync -P test_60gb.tar /nfsmount 修改/etc/exports然后执行从 50 MB/秒到 100 MB/秒的变化exportfs -arv。拥有proto=tcp 和 sync对于 NFS 的性能来说绝对是不利的。

我还没有机会去尝试proto=udp，事实上，我很难做到这一点。

相关内容