![NFS 服务器对客户端无响应 - 进程“迁移”和“xfssyncd”消耗了异常 CPU](https://linux22.com/image/623063/NFS%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%AF%B9%E5%AE%A2%E6%88%B7%E7%AB%AF%E6%97%A0%E5%93%8D%E5%BA%94%20-%20%E8%BF%9B%E7%A8%8B%E2%80%9C%E8%BF%81%E7%A7%BB%E2%80%9D%E5%92%8C%E2%80%9Cxfssyncd%E2%80%9D%E6%B6%88%E8%80%97%E4%BA%86%E5%BC%82%E5%B8%B8%20CPU.png)
我有一台运行 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 安装程序似乎没有办法拦截警告,并不断下载超过软限制的文件。这产生了大量的配额警告,完全拖慢了系统,使其无响应。
我说“似乎”是因为证据是间接的。当用户尝试安装到没有配额的目录中时,一切都很顺利。