NFSv3客户端在读写性能上的差异

Question

我正在处理一些服务器，这些服务器使用NFS文件器相对较多。

在关键时刻，一台服务器以每秒2k的速度向文件发送大约2k的读+2k写操作。根据nfsiostat的说法，在这段时间，读写RTT从通常的5-10 is增加到50-100 is( r/w )。nfsiostat的平均执行时间对于读和写则有很大的不同:读大约200 is，写100到200秒。

现在，我了解到nfsiostat中的平均执行时间本质上是RTT +内核时间(RPC队列等)。谈到RPC --我看到了在RH5.8 (RPC在关键时刻约为5k )和RH6.3 (在任何时候都有RPC 0)上的完全相同的行为。

所以-问题: NFS读/写执行时间如此不同的原因是什么？

( NFS调用是由专有应用程序进行的，我没有多少可见性。)同样适用于备案者(NetApp -外包)。内核跟踪可能也不是一种选择)

先谢谢你。

编辑:为了澄清，并且因为我得到了一些关于NFS性能的答案--我真正感兴趣的唯一部分是:根据nfsiostat doco，“.客户端的内核发送RPC请求到它收到回复时的持续时间。”Avg是“. NFS客户端对其内核执行RPC请求直到完成RPC请求的持续时间，这包括上面的RTT时间”(http://man7.org/linux/man-pages/man8/nfsiostat.8.html)。

我(也许很天真)的理解是，在RTT之后，服务器就完成了，超出了等式。那么，当RTT相同时，NFS客户端会做什么，Avg在读/写方面是如此不同呢？

Answer 1

根据所描述的情况，有可能存在多种因素。sync和async选项会对性能产生重大影响，安装NFS时的nolock选项也会对性能产生重大影响。

在挂载时，与文件的ACL相关的文件所有权和权限问题以及/或root_squash和no_root_squash选项的使用可能会影响性能。不过，如果是这样的话，很可能会在某个地方的日志中找到它的证据。

在内存中或从内存中移动文件也可能会出现问题。根据操作的顺序以及物理和虚拟内存的数量，也可能会发生大量的震荡。

如果通信正在进行，而且文件操作没有被正确清除/挂起/占用过多时间来完成写操作，那么当前打开的文件数可能会开始推高内核支持的限制，可以通过运行以下命令来检查：

cat /proc/sys/fs/file-max

如果NFS服务器或客户端的值较低，则可能值得增加该值，以查看性能是否有所提高。根据网络环境的不同，实现某些QoS策略可能会对性能产生影响(虽然不太可能)。