CentOS 6.9 NFSv4服务器高CPL问题：重启NFS仅临时缓解

兄弟，我之前在运维CentOS 6.9的NFSv4服务器时碰到过几乎一模一样的问题，结合你描述的症状，给你梳理几个实用的排查方向和解决办法：

你说本地访问正常但客户端慢，atop显示CPL（CPU运行队列长度）飙到100+，重启NFS后暂时恢复但几分钟又复发——这说明问题肯定出在NFS服务的请求处理链路上，大概率是某个请求类型或者客户端把NFS服务端的资源给占满了，本地绕开了NFS协议栈所以没问题。

• 抓包定位异常请求/客户端
  先抓NFS的流量包，等CPL升高后停止分析：

  tcpdump -i any port 2049 -w nfs_traffic.pcap
  

  然后用tshark统计请求来源和类型：

  tshark -r nfs_traffic.pcap -T fields -e ip.src -e nfs.procedure | sort | uniq -c
  

  看看是不是某个客户端在疯狂发请求（比如频繁的GETATTR或者大文件WRITE），或者有没有异常的NFS操作类型。我之前碰到过某个客户端的备份脚本每秒发几百次元数据请求，直接把NFS线程池堵死了。

• 调整NFS服务端线程数
  CentOS 6默认的NFSv4线程数（RPCNFSDCOUNT）只有8，高并发场景下很容易被占满。修改/etc/sysconfig/nfs文件，找到RPCNFSDCOUNT参数，改成16或者32：

  RPCNFSDCOUNT=16
  

  然后重启NFS服务：

  service nfs restart
  

  这个调整能直接提升服务端的并发处理能力，很多时候重启后复发就是因为线程池又被占满了。

• 排查NFSv4身份映射（idmapd）问题
  NFSv4依赖rpcidmapd做用户身份映射，如果这个服务配置有问题（比如DNS解析慢、域配置和客户端不一致），每个请求都会卡在身份验证环节，导致CPU队列暴涨。

  1. 检查/etc/idmapd.conf里的Domain字段，确保和所有客户端的NFSv4域一致；
  2. 重启rpcidmapd服务：

     service rpcidmapd restart
     

  我之前碰到过客户的DNS服务器挂了，idmapd每次解析用户域名都超时，直接把NFS服务拖垮了。

• 检查导出文件系统的挂载参数
  虽然本地访问正常，但NFS导出的文件系统如果没开优化参数，会导致服务端处理元数据请求变慢：

  • 用mount | grep 你的导出卷路径查看挂载参数，确保有noatime（减少元数据写入）；
  • 如果是ext3/ext4文件系统，用tune2fs -l /dev/你的磁盘设备 | grep dir_index确认开启了目录索引，这个能大幅提升目录遍历的性能。

• 清理僵死的RPC进程
  有时候rpc.nfsd或者rpc.mountd进程会僵死，占用资源却不处理请求，导致新请求排队。用ps aux | grep rpc看看有没有状态为Z（僵尸）或者长时间无响应的进程，用kill -9杀掉后重启NFS服务即可。

如果暂时找不到根因，需要先保证业务可用，可以设置一个定时任务每隔几分钟自动重启NFS服务：

crontab -e

添加一行：

*/5 * * * * /sbin/service nfs restart > /dev/null 2>&1

注意：这个操作会短暂中断NFS服务，适合临时应急，还是建议尽快排查根因彻底解决。

内容的提问来源于stack exchange，提问作者Michael S