我有一个运行NFS 4的CentOS 6.4文件服务器，服务于几个XFS文件系统。 有几十个客户端连接到它。 今天，它减缓了客户端的爬行速度 – 客户端会挂起，或者在从服务器访问挂载的NFS共享几分钟后才响应。 在服务器本身上，我可以毫不费力地访问共享文件系统。 大约四个小时后，麻烦就消失了，但是我不知道为什么 – 请看下面。
top显示了几个migration过程和xfssyncd进程消耗不寻常的CPU数量，跳跃之间0％和任何地方高达100％，每隔几秒钟。 没有其他进程显着活跃。 上面报告的整体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
我一直无法在网上find任何关于这个问题的话题，除了可能来自仅在其用户部分中的RHEL支持条目，我看不到。
我运行service nfs restart 。 然后service nfs status显示正在运行的守护进程，除了nfsd dead but subsys locked 。 在又一次重启之后，这个消失了，nfsd正在运行，但是客户端仍然被挂起。
我尝试了一些与xfssyncd相关的问题：
1）在导出的fs上mount –o remount /mnt/data 。 有趣的是，这个命令花了一分钟左右的时间，而在这段时间里，这个“狂野”的进程安顿下来。 但是一旦命令完成运行，进程就回到了高CPU使用率。
2） echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecs以更改xfssyncd的同步间隔。 这并没有引起任何显着的差异，这并不令人惊讶，因为fs忙于NFS客户端，问题一定是别的。
3个星期前，我在这台服务器上遇到了一个问题，一个.nfsNNN文件（来自被删除的文件仍然是打开并被访问的）在客户端快速填充了循环错误消息。 杀死问题进程修复了NFS放缓。 [但是文件服务器在几天之后再次减速，没有出现这样的.nfsNNN文件问题，我最终不得不重新启动它。 当时我看到一些cpu级别非常高的进程，但是没有注意到它们是什么，现在也不记得了，如果它们与当前版本相同。]
我今天再次search打开.nfsNNN文件可能是问题，但没有发现。 我从几个月前删除了一些，但他们目前还没有被修改，所以认为它们不是问题。 删除这些文件后，我注意到没有区别。
尝试上述各种操作大约一小时后，服务器恢复正常， migration和xfssyncd进程不再具有较高的CPU使用率。 我不知道发生了什么变化，但是我想尝试一下，弄清楚这一点，因为看起来可能会再次发生。
感谢您的任何build议。
-M