我有一台运行 NFS 4 的 CentOS 6.4 文件服务器，为几个 XFS 文件系统提供服务。有几十个客户端连接到它。今天，它对客户端来说变得非常缓慢 - 当从服务器访问已挂载的 NFS 共享时，客户端会挂起或几分钟后才响应。在服务器上，我可以毫无问题地访问共享文件系统。大约四个小时后，问题消失了，但我不知道原因 - 见下文。
top显示几个migration进程和xfssyncd进程消耗了异常数量的 CPU，每隔几秒钟就会在 0% 和 100% 之间跳跃。没有其他进程明显活跃。top 报告的总体 CPU 使用率很低，如下所示：
Cpu(s): 0.0%us, 4.2%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
我无法在网上找到任何专门讨论此问题的内容，除了 RHEL 支持条目（位于其仅限订阅者部分）之外，我看不到。
我运行了service nfs restart。然后service nfs status显示正在运行守护进程，除了nfsd dead but subsys locked。再次重启后，这个消失了，nfsd 正在运行，但客户端仍然挂起。
我尝试了一些针对 xfssyncd 相关问题建议的方法：
1)mount –o remount /mnt/data在导出的 fs 上。有趣的是，这个命令大约需要一分钟才能运行，在此期间，“狂野”进程会稳定下来。但是一旦命令运行完毕，进程就会恢复到高 CPU 使用率。
2)echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecs以更改 xfssyncd 的同步间隔。这并没有带来任何明显的区别，这并不奇怪，因为 fs 正忙于处理 NFS 客户端，问题肯定是其他原因。
三周前，我遇到了此服务器的问题，其中一个 .nfsNNN 文件（来自已删除的文件，仍处于打开状态并正在访问中）正在快速填满，客户端上出现循环错误消息。终止问题进程解决了 NFS 减速问题。[但是几天后，文件服务器再次减速，没有出现这样的 .nfsNNN 文件问题，我最终不得不重新启动它。当时我看到一些进程的 CPU 水平异常，但没有注意它们是什么，现在不记得它们是否与当前问题相同。]
我今天再次搜索了可能有问题的打开的 .nfsNNN 文件，但一无所获。我确实删除了几个月前的一些文件，但它们目前没有被修改，所以认为它们不是问题。删除这些文件后，我注意到没有任何区别。
尝试上述各种方法后大约一小时，服务器恢复正常，并且migration进程xfssyncd不再占用过多的 CPU。我不知道发生了什么变化，但我想尝试提前找出原因，因为这种情况似乎可能会再次发生。
谢谢您的任何建议。
-M
答案1
我的 RHEL 6.10 也存在类似的问题。唯一似乎有帮助的方法是终止 NFS 客户端上长时间运行的用户 sftp 进程。这些进程是由基于 GUI 的 SFTP 客户端（例如 WinSCP、Nimble Commander）保持打开数小时（超过 10 小时）的。
监控显示一些 NFSv3 客户端活动与问题同时发生，但该活动实际上低于其他客户端（有 > 100 个客户端）上不会导致问题的一些其他典型活动。
实际上也没有完成很多的 i/o。
更新 2019-12-10：根本原因似乎是 NFS 服务器上的 XFS 配额。用户主目录有配额限制，软限制比硬限制低 2 GB。一些用户尝试安装完整的 Anaconda Python，这超出了软限制。Anaconda 安装程序似乎没有办法拦截警告，并不断下载超过软限制的文件。这产生了大量的配额警告，完全拖慢了系统，使其无响应。
我说“似乎”是因为证据是间接的。当用户尝试安装到没有配额的目录中时，一切都很顺利。