一、组网图

略（和NAS组网方式无关）

二、问题描述

用户反馈NFS共享文件夹访问慢，文件解压极慢。

三、过程分析

1、watch "ps -aux | grep nfsd" 实时检查nfsd进程s状态存活的数量，如大量nfsd进程长时间处于D状态，只有1-2个S状态进程则代表NFS服务不正常。

3、以上，基本判定NAS服务端存在TCP发送缓冲区满现象，该现象会导致nfs 请求发送阻塞，报文持续大量重传，客户端NFS访问出现性能问题。现场触发的根因是由于客户端到NAS的网络丢包率达0.5%-0.7%。

原理简述：

    在丢包场景下， 多个 nfsd 线程将客户端请求响应数据写入 TCP 连接发送缓冲区时由于 未能收到来自客户端的ACK回复，导致 TCP 发送缓冲区中的“已发送但未收到确认”的部分释放缓慢，发送窗口无法正常滑动。

    多个 nfsd 线程将客户端请求响应数据写入 tcp 连接发送缓冲区。 nfsd 发送数前为保证发送数据的线程安全，会首先获取一个传输对象的互斥锁 (mutex) ，等待 mutex 的 nfsd 线程进入 D 状态，持有 mutex 的 nfsd 线程进入 S 状态。此时持有锁的 nfsd 线程申请发送缓冲区缓存异常缓慢，长时间无法释放锁，其他 nfsd 线程在响应相同问题客户端请求的数据时无法获取锁发送数据，导致整个业务性能异常缓慢

四、解决方法

1、分析出卡顿原因是NAS侧TCP发送缓冲区满后，尽快找出导致问题的客户端IP。

使用 iftop -i eth_nas_3 -t  命令，实时监控IP流量。eth_nas_3 为现场的业务接口，具体根据现场情况判断。

现场观察到发送流量TOP1的客户端IP长时间保持在122.16.62.96，怀疑是该客户端存在异常。

2、使用watch “nestat -apn | grep 122.16.62.96” 和watch “netstat -apn | grep 2049”命令，实时监控可疑客户端IP send -q网络发送队列的堆栈情况，进一步对比发现网络发送堆栈严重。基本确定是该IP导致的NAS侧TCP发送缓冲区满。

后面抓包也发现该IP存在大量重传

3、迅速将客户端IP上报给客户，登录检查客户端运行状态，停止其nfs业务并检查nas侧nfsd进程状态是否大量恢复s状态。（现场客户端停止业务下发后，nfsd进程状态恢复正常，不再长时间只有1个进程S状态）

4、问题客户端指定rsize、wsize=262144 （256K）参数，重新挂载。并使用mount | grep NFSIP 命令检查是否生效。后续所有在用的客户端同步整改。

mount -o vers=3,rsize=262144,wsize=262144 NFS_IP:/共享目录 /目标目录

解决问题的逻辑：

NFS 的rsize和wsize参数决定了客户端与服务器之间单次网络交互可以读写的数据块大小，在客户端挂载配置的基础上，客户端和服务器端还会共同协商这两个参数的最终值，以确保它们既不超过NAS存储和客户端所允许的最大值。我司存储目前最大支持的rsize/wsize为1M，现场客户端挂载时未指定rsize/wsize协商结果为1M。较小的rsize/wsize在丢包环境下有以下优势： 客户端请求的数据块越小，则nfsd每次响应发送的数据量就越小，申请的缓冲区越小就约容易满足。 较小的数据块即使发生丢包，也仅影响小部分数据，从而减少了重传的开销和对性能的影响，提高传输效率。 

5、目前在NAS_V2.0.27T06P18、NAS_V3.1.3T05以前版本，默认的客户端挂载size都为1M，若发生此类问题，只能重新指定客户端rsize和wsize参数为256K优化解决。后续版本已扩大TCP缓冲区并将默认挂载size调整为256K

五、风险提示

1、停止客户端的NFS业务需要和客户再三确认，避免误操作。

2、指定参数重新挂载无风险，部分友商也使用256K的rsize/wsize参数挂载。

3、若想通过升级NAS版本规避，必须先把客户端全部重新指定参数挂载，否则升级后由于size参数协商问题，业务会中断。

六、关键字

NAS，NFS，性能调优，性能卡顿，rsize，wsize，mount，