我正在负责一些相对大量使用 NFS 文件器的服务器。
在关键时刻，单个服务器每秒向文件管理器发送大约 2k 次读取 + 2k 次写入。根据 nfsiostat，此时读写 RTT 从通常的 5-10ms 增加到 50-100ms。但是根据 nfsiostat，读取和写入的平均执行时间截然不同：读取大约 200ms，写入在 100-200 秒之间。
现在据我所知，nfsiostat 中的平均执行时间基本上是 RTT + 内核时间（RPC 排队等）。谈到 RPC - 我看到 RH5.8（关键时刻 RPC 积压约 5k）和 RH6.3（RPC 积压始终为 0）上的行为完全相同。
那么 - 问题是：NFS 读/写执行时间差异如此之大的原因是什么？
（NFS 调用由专有应用程序进行，我对此了解不多。文件管理器（NetApp - 外包）也是如此。内核跟踪可能也不会成为一种选择）
提前非常感谢您。
编辑：澄清一下，因为我得到了一些关于 NFS 性能的答案 - 真正让我感兴趣的部分是：根据 nfsiostat doco，RTT 是“...从客户端内核发送 RPC 请求到收到答复的持续时间。” 和 Avg Exe 是“...从 NFS 客户端向其内核发出 RPC 请求到 RPC 请求完成的持续时间，这包括上面的 RTT 时间。”（http://man7.org/linux/man-pages/man8/nfsiostat.8.html）。
我的理解（可能有点幼稚）是，RTT 之后服务器就完事了，不再适用。那么 NFS 客户端做了什么，导致 RTT 相同时读/写的平均 Exe 差异如此之大？
答案1
根据所描述的场景，可能有多个影响因素。 sync并且选项可能会对性能产生重大影响，挂载 NFS 时的选项async也会对性能产生重大影响。nolock
性能还可能受到文件所有权和权限问题的影响，这些问题与文件的 ACL 和/或挂载时使用root_squash和no_root_squash选项有关。不过，如果是这种情况，日志中可能会有相关证据。
在将文件移入或移出内存时也可能出现问题。根据操作顺序以及物理和虚拟内存的数量，还可能会发生大量抖动。
如果流量正在进行并且文件操作未正确清理/挂起/花费过多时间完成写入操作，则当前打开的文件数量可能会开始超过内核支持的限制，可以通过运行以下命令进行检查：
cat /proc/sys/fs/file-max
如果 NFS 服务器或客户端上的该值较低，则可能需要增加该值以查看性能是否得到改善。根据网络环境，实施某些 QoS 策略可能会对性能产生影响（尽管可能性不大）。