nfs和D（disk sleep）状态卡死进程的那些事_nfs瓶颈

 

有些博主，dmesg和/proc/pid/stack信息看不懂就别瞎几把往外贴

贴了你倒是分析一下啊

for example：

我写这篇帖子时也不懂- -，搜索很多内容后发现网上一堆复制粘贴的内容，并没有实质性的分析与探讨，反而国外的论坛里这类讨论更多些。

先说下我的分析，背景是：

nfs服务端（1台） 内存buff/cache 90%，available 90%，top命令中wa为15左右；存在一定的io负载。

iotop磁盘总写速率为50M每秒（目前nfs的瓶颈了，我的优化空间可能还不够）

nfs 客户端（一共15台，即上图错误所在的服务器是其中一台 ）  内存信息同服务端，top 命令中wa 30~50左右，cpu利用率很低，load avge 1000+(没看错，就是这么高），客户端上Iotop中读和写总速率才200KB左右

分析正文：

客户端iotop读写速率和iowait不成比例，正常情况下读写速率很大才会伴有iowait的发生，此现象说明瓶颈并不是在磁盘io中，应该在网络存储nfs，nfs客户端速率为什么这么低呢，我认为是nfs server端采用了sync模式传输数据，在nfs 的sync模式中出于数据安全性，会依次排队处理客户端的请求，此时nfs客户端多线程程序对nfs目录触发的请求得不到满足，不断增加io负载，造成nfs内存缓冲页数据交换失败（你们就听我扯吧，技术不行，目前只是分析）。

内存缓冲页数据交换：

目前对这个名词不怎么了解，感觉和这两个有关（有理解的可以分享一下）：

# sysctl -a | grep dirty | grep ratio
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
 
# vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如5%）就会触发pdflush/flush/kdmflush等后台回写进程运行，将一定缓存的脏页异步地刷入外存；
 
# vm.dirty_ratio:而这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存）；在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。
 
# dirty_background_ratio 在dirty_ratio之前

这次问题的发生，我并没有修改上图两个值，而是将nfs sync模式改为async模式，因为我觉得这是nfs server端引起的，客户端资源io阻塞，以此来加快传输速度。并且增客户端的timeo项，延长nfs客户端等待时间。

其实主要问题还是在于nfs-server文件存储数据传输的速率，目前我这边最大写速率为50M/s。如果有更高的配置方式，请留下一些及建议。

目前我的配置形式：

Nfs server端配置：
 
rw,fsid=0,async,no_subtree_check,no_auth_nlm,insecure,no_root_squash
 
Nfs client端配置：
 
-o rsize=1048576,wsize=1048576,hard,intr,timeo=5,retry=10

---

2022年12月2日更新：

https://developer.aliyun.com/article/25448

上述链接给了一些方式测试，有一些我曾做过：

部分nfs  D进城在server段资源缓和后会自动消失，在华为存储共享出来的nfs-server上有见过，但有时你会看到有个k8s  pod已经terminating两三个月，放弃幻想它不会消失，这种情况理论上卸载会解决，但是这个pod已经处于回收中，无法进入释放，所以它只能做个卡死并且无法回收的进程，可以尝试干掉rpcbind进城试试

其主要原因，nfs-server的性能瓶颈，大多来自于磁盘响应

能激发这个瓶颈的只有超大量的io请求，你是集群环境吗，是的话想改善就换分布式存储

换不了只能缓和这个瓶颈：

如果你只维护一套集群，会更容易解决这个问题：

尝试nfsv3版本 ，

server端 指定sync模式，和取消时间戳，所有权等等需要验证的功能

客户端挂在参数为 async hard intr timeo=600 retrains=2

更改内存dirty写入比率，越小，写入越快写，避免内存写入磁盘的io风暴，调整server端的io算法（这个目前还未做过）