nfs 端口_Linux挂载NFS，偶发执行df命令卡顿

背景

使用一台机器通过挂载scsi硬盘，然后通过nfs共享出去给客户端使用。

现象

客户端在使用的时候，出现nfs的文件系统极其的慢，执行df 命令，还会直接卡住约20秒左右

分析过程

判断df卡住的地方

在客户端机器，查看cpu、内存，网卡流量等，均很低，处于正常状态。

在执行df命令的时候，通过strace，跟踪执行情况，

卡在nfs文件系统的stat部分。

判断是否为网络问题

在客户端和server端，同时开启抓包，然后执行df命令，查看两边数据包收到的延时 抓包命令

# clien端
tcpdump -i eth1 \(tcp src port 812 and tcp dst port 2049\) or \(tcp src port 2049 and tcp dst port 812\) -w client04.pcap

# server端
tcpdump -i bond1 \(tcp src port 812 and tcp dst port 2049\) or \(tcp src port 2049 and tcp dst port 812\) -w server-04.pcap

抓包指定了nfs的端口。

发现client和server端收到的包没有延迟，客户端发包之后，服务端里面就收到，服务端发出之后，客户端也立马就收到，即表示链路上没有延迟。但是两次发包间隔时间较长，这就是卡顿的地方。

判断后端盘是否为瓶颈

由于客户存放的小文件较多，在server端进行小文件读写测试，整体iops较小，但是时延正常。

同时在，server端开启磁盘iostat监控，发现，卡顿的同时，部分文件系统的盘util在100%左右。

同时伴随着NFSD进程有卡住状态

初步结论

客户端使用的nfs v4协议进行挂载 nfs v4协议open/close为串行的，server上挂载了多个盘，建了了多个文件系统，共享出去。如果后端某一个磁盘响应慢，会拖慢其他其他盘的nfs请求。

建议客户使用v3协议进行挂载

最终解决

客户通过v3挂载，并将一些频繁读写的文件迁移出文件系统，还是会偶发卡顿现象。

在server 端查看nfsd进程，还是有D住的情况，所以导致了卡顿。

这里的原因是，在server 端默认的nfsd进程的数量，导致了卡顿。可以通过调大server端nfsd的进程数。临时修改，修改方法，重启后失效。

echo 256 > /proc/fs/nfsd/threads

• 永久修改

修改 /etc/sysconfig/nfs 配置文件RPCNFSDARGS=256

总结

nfs的卡顿网络、盘的原因，nfs本身的原因，都是可能的。

这里列举了几个场景的排查思路和方法，在定位nfs的问题的时候供参考。