爬一手好线杆登录服务器准备例行巡检，发现load average已经飙到25。top命令按下去，CPU的us只有3%，wa占到了90%以上，下面密密麻麻的进程全是D状态。我扫了一眼iowait，果然红得发紫。这种"机器没死、但所有IO都在原地打转"的场面，我遇到的次数不算少。D状态就是不可中断睡眠，进程在内核态等着某个IO完成，等不到就永远睡在那一行，kill -9都拿它没办法。最要命的还不是等，而是你不知道它在等什么、等的是哪个文件。所以每次碰到这种场景，我的标准动作都一样：把长时间D状态进程的内核堆栈打印出来，再把它们手上握着的文件绝对路径全部挖出来，真相基本就藏在这两样东西里。这篇文章就是把这条排查链路完整拆开，从定位进程、抓堆栈、挖路径到自动化脚本，一步不落。方法不依赖玄学，全是/proc文件系统、内核栈跟踪和文件描述符解析的硬功夫，你在生产环境里一样能复现。
1. D状态和iowait：先搞懂你面对的是什么问题
1.1 D状态到底是什么，为什么比R状态更难缠
Linux进程状态里有几个常见字母：R是运行态，S是可中断睡眠，D就是不可中断睡眠，Z是僵尸，T是停止。D状态的全称叫TASK_UNINTERRUPTIBLE，意思是这个进程已经进入了内核态，正在等待一个不能被打断的内核操作完成。典型场景是等待磁盘I/O、等待NFS网络回包、等待锁、等待内存回收等。
为什么说D状态比R状态难缠？进程在R状态，说明CPU不够用，你通过top能清楚看到谁在消耗CPU，可以调整进程优先级，可以随时kill掉让它重来。但D状态不一样——进程已经在内核里睡过去，信号机制对它完全不生效，kill -9发过去也没反应，只能干等内核把那个I/O完成。更要命的是，进入D状态的进程会被计入load average。Linux的load值统计的就是R状态和D状态进程的总数，所以当你看到load很高、CPU却是闲的时候，不用怀疑，大概率是有一堆进程卡在D状态。
不过要强调一句：D状态短暂出现是正常的。任何一次磁盘读写都可能让进程在D状态待上几十毫秒甚至几秒，比如内存页换出、文件系统journal提交。真正需要警惕的是"长时间"D状态。我个人的经验阈值是超过30秒，如果整个系统里同时出现几十个长期D状态的进程，那基本不用怀疑，存储链路肯定出了大问题。
1.2 iowait升高不等于存储一定挂掉
iowait的含义是CPU处于空闲状态、同时在等待I/O完成的时间比例。很多人一看到wa高就觉得磁盘坏了，这是个误解。iowait高只能说明CPU在等I/O，并不能直接判断I/O能力有问题。比如系统刚开机，需要从磁盘读大量文件到page cache，这时候wa高是正常现象；再比如你人为执行dd从一个盘往另一个盘拷贝大文件，CPU可能也会大量时间在等I/O完成。
所以遇到wa高，先别急着下结论。正确的做法是看iowait的变化趋势、看具体哪些进程在D状态、再看I/O设备的利用率。这里可以参考vmstat的输出：如果r列（运行队列）也很高，说明既有CPU压力又有I/O压力；如果r列很低、b列（阻塞进程）很高，那就是I/O压力的典型表现。另外最好用iostat -x 1看各个设备的%util和svctm，把"进程D在等哪个设备"和"这个设备的服务能力"对应起来。等半天只能靠猜，有了设备层面的数据才能往下走。
我在实际排查中还发现过一个细节：iowait是全局CPU维度的统计，并不是按进程来算的。所以哪怕只有一个进程在疯狂读盘，它可能只让其中一颗CPU的wa变高，在top里看起来却是整体wa不算离谱。这种情况下，只看wa容易漏掉问题，必须结合进程状态和I/O统计来看。
1.3 判断"必须抓堆栈"的几个场景
不是所有D状态都需要大动干戈抓堆栈。判断标准很简单：D状态持续时间长、数量多、且影响了线上服务，那就必须动手。我总结过几个反复出现的典型场景：
- 存储多路径或磁盘阵列故障：进程大面积进入D状态，iostat显示某个设备util接近100%，但读写量不大，可能是链路问题而不是真实负载。
- 文件系统卡顿：ext4、xfs等文件系统的journal提交线程卡死，用户进程读写文件时全部堵在日志提交环节，堆栈里能看到jbd2相关函数。
- 网络文件系统故障：NFS、CIFS这类网络文件系统最坑，服务端宕机或网络抖动会让客户端进程长时间D在RPC等待上，堆栈里通常有nfs和rpc关键函数。
- 内存回收和page cache回写问题：大量脏页需要回写，但存储设备响应极慢，导致进程卡在writeback等待路径上。
上面这些场景，光看进程状态分不清谁是谁，只有把它们的内核堆栈和访问的文件路径挖出来，才能快速区分是哪个子系统出了问题。这就引出下文的具体操作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 锁定"霸榜"的D状态进程
2.1 一条命令快速筛出所有D状态进程
第一步永远是先找出来哪些进程处于D状态。最简单的命令是ps配合awk：
bash复制ps -eo state,pid,ppid,wchan:32,comm | awk '$1=="D"'
这个命令会列出状态为D的进程，显示PID、父进程、内核等待点和进程名。不过ps的wchan列默认截断得比较短，32列以内的函数名基本够看，再长就得去/proc里看完整版。
如果想把信息打得更全，可以用下面这个更直接的方式，遍历/proc目录：
bash复制for pid in $(ls /proc | grep -E '^[0-9]+$'); do
if [ -r /proc/$pid/stat ]; then
state=$(awk '{print $3}' /proc/$pid/stat)
if [ "$state" == "D" ]; then
comm=$(cat /proc/$pid/comm 2>/dev/null)
echo "PID: $pid STAT: D COMM: $comm"
fi
fi
done
/proc目录下每一个数字目录都对应一个进程，stat文件里第三个字段是进程状态。这种遍历方式的好处是拿到PID之后可以直接用，不需要再二次解析ps输出。当时在生产环境排查，我用这个循环加一个管道排序，几秒钟就能把全量的D状态进程筛出来。
2.2 怎样判断一个进程已经D了很久
只看到"现在是D状态"还不够，还要知道它D了多久。麻烦的是，/proc/PID/stat里并没有D状态持续时间的字段。进程的cpu时间、启动时间都有，唯独没有"进入D状态的时刻"。
所以要用采样法：先记录下当前所有D状态进程的PID和时间戳，过一段时间再采样一次，如果一个PID在两次采样中都是D状态，那它至少D了这么久。重复多轮可以更精确。原理不复杂，但写脚本时要注意竞态问题：进程可能在两次采样之间短暂从D状态切到R或S状态，然后又回到D状态，所以纯靠两次采样可能会漏掉。更稳妥的做法是每1秒采一次，连续采5到10次，把那些"每次都出现"的进程挑出来，基本就是真正长时间卡死在D状态的。
内核本身其实还有一个辅助机制，就是hung task检测。当一个任务长时间处于D状态（内核默认阈值是120秒），hung_task机制会往内核日志打印一条警告，里面带了进程的堆栈信息。这个开关可以通过/proc/sys/kernel/hung_task_timeout_secs调整。我在排查长期IO问题时，会先把这个阈值临时调小，比如调到30秒，让内核帮忙提前抓到现场，比自己轮询更可靠。不过注意，这个参数在生产环境要慎改，调太小吃性能日志太频繁，容易干扰判断。
2.3 top、ps、atop中容易误解的信息
用top看D状态进程时，很多人会把D和R混在一起。top默认按CPU排序，如果没按状态过滤，D状态进程因为CPU时间为0，往往排在列表很后面，一眼看不见。排查时建议直接按状态排序：top里按O键再按P键，选择STAT字段排序，或者直接在top界面里按U键输入D来过滤。atop工具更直观一些，进程列表里DSTATE列会显示D，同时DSRC列会显示导致睡眠的详细内核原因，这个信息对快速判断很关键。比如DSRC显示"IO"说明在做块设备读写，"VM"可能在做内存相关等待，"NET"则可能跟网络协议栈有关。理解这些字段的含义，才能在第一时间缩小排查范围。
3. 把内核堆栈打出来：proc、sysrq和crash三条路
3.1 最直接的 /proc/PID/stack 及其权限坑
拿到PID之后，第一件事就是读它的内核堆栈。/proc/PID/stack文件会输出当前进程在内核态的调用栈，这是定位卡死点的关键数据。操作很简单：
bash复制cat /proc/PID/stack
输出大约长这样：
text复制[<0>] blk_flush_plug_list+0x1b8/0x230
[<0>] blk_queue_bio+0x10e/0x120
[<0>] generic_make_request+0xbd/0x140
[<0>] submit_bio+0x38/0x80
[<0>] ext4_mpage_readpages+0x1d7/0x2c0
[<0>] read_pages+0x82/0x140
[<0>] __do_page_cache_readahead+0x17f/0x1e0
...
读这个文件有两个硬性门槛。第一是权限，必须root或者有CAP_SYS_ADMIN能力，普通用户连文件都打不开。第二是内核编译时必须开启CONFIG_STACKTRACE选项，绝大多数发行版的内核都开了，但如果你用的是自编译精简内核，可能读不出来。还有一个坑需要提醒：因为堆栈打印出来的是当前的瞬时调用栈，如果你的进程在D状态和正常状态之间快速切换，抓出来的栈可能不是D状态那一刻的，所以抓之前最好先用前面提到的采样法确认它确实长时间停在D状态。
3.2 系统级的全量堆栈：sysrq-trigger
如果D状态的进程很多，不想一个一个cat，可以用sysrq把全系统的进程堆栈一次性打出来：
bash复制echo t > /proc/sysrq-trigger
这个操作会触发内核把所有进程的内核堆栈写到内核日志里，然后用dmesg查看：
bash复制dmesg -T | grep -A 40 "task:"
输出的内容会包含每个进程的任务名、PID和完整的内核堆栈。它的原理是让内核针对每个任务触发一次栈回溯，所以即使有些进程不是D状态也能一并看到，方便对比。使用前要确认/proc/sys/kernel/sysrq的值不等于0，如果被关掉了，先执行echo 1 > /proc/sys/kernel/sysrq临时打开。这个操作本身不重，但在IO卡死的机器上，打印大量堆栈会加重内核日志写入压力，所以别反复执行，抓一次就够了。
还有一种更重型的手段是用crash分析vmcore，需要提前配置kdump，在系统真正挂掉后通过内核转储文件离线分析。这个方法能看的东西更多，比如内存中的活动文件、ext4日志状态、块设备请求队列等，但因为你已经在用/proc抓堆栈了，大多数场景还没到那一步，把它作为后备方案记住即可。这里顺便提一句：如果D状态持续到完全无法响应，hung_task最终会触发内核panic（如果配置了panic_on_oops），那时kdump就派上用场了。
3.3 用户态堆栈那点事：D状态进程不能gdb attach
读内核堆栈只是看到了一半，很多人还想要用户态堆栈，看看进程是在调用哪个库函数时进入的IO。但这里有个大坑必须说清楚：D状态进程是内核态不可中断睡眠，gdb attach上去会试图用ptrace机制停止进程，这对D状态进程通常无效，attach操作会一直卡住，甚至把gdb自己也拖死。pstack底层也是gdb，同样不行。所以不要浪费时间去attach D状态进程。
如果真的需要用户态堆栈，只能想办法提前布防。比如在应用的启动脚本里加上perf record -g -p PID，等系统恢复后再用perf report看采样数据；或者对动态库函数用uprobe/ebpf挂探针。这些方案在多数IO故障场景下要么过于复杂、要么当时没开，所以我个人经验是：优先吃透内核堆栈，内核栈里看到的函数已经能定位到具体内核子系统，再配合后面讲的fd路径信息，绝大多数问题已经可以下结论。
3.4 wchan和syscall：轻量级辅助定位
如果只是想快速确认进程卡在哪个内核函数，不需要完整堆栈，直接看/proc/PID/wchan和/proc/PID/syscall会更轻量：
bash复制cat /proc/PID/wchan
cat /proc/PID/syscall
wchan输出的是进程当前睡眠的函数名，比如io_schedule、rpc_wait_bit_killable，一看就知道是在等IO还是在等网络。syscall输出格式是"系统调用号 参数列表"，还会附带当前指令指针和栈顶指针，能知道它正在执行哪个系统调用。这两个文件读起来怎么都比stack轻，在只想知道"大概卡在哪"的时候，效率最高。我一般会用wchan做快速分类，把所有D状态进程的wchan排个序、去个重，哪些卡在同一类的就非常清楚了。
4. 挖出相关文件的绝对路径：fd、maps到mount逐层剥开
4.1 /proc/PID/fd：信息量最大的入口
光知道卡在内核的哪个函数还不够，你得知道它到底在访问哪个文件。这个信息藏在/proc/PID/fd目录里。每个打开的文件描述符都会在这里生成一个符号链接，链接的目标就是文件的绝对路径：
bash复制ls -l /proc/PID/fd
输出类似这样：
text复制lrwx------ 1 root root 64 3月 21 11:22 3 -> /var/log/nginx/access.log
lrwx------ 1 root root 64 3月 21 11:22 4 -> /data/mysql/ibdata1
lrwx------ 1 root root 64 3月 21 11:22 5 -> socket:[1234567]
lrwx------ 1 root root 64 3月 21 11:22 6 -> /data/mysql/undo_001
那些指向普通文件的符号链接，就是你找的相关文件绝对路径。如果看到的是socket、pipe、anon_inode，说明这个fd不是文件，需要结合堆栈判断它在等什么。但有一个细节容易踩：fd目录和链接本身放在虚拟文件系统里，即使进程已经打不开这个文件、或者文件被删了，符号链接依然会显示原来的路径，这恰恰是后面要说的(deleted)线索的来源。
一个进程同时打开的fd可能很多，要快速分辨哪些跟D状态相关，可以先看堆栈里出现的是哪个子系统。比如堆栈里看到ext4相关函数，那重点就看指向块设备或文件系统内文件的fd；看到nfs相关函数，就看是不是有指向NFS挂载点路径下的fd。把堆栈和fd对照起来看，而不是一上来就把所有fd挨个翻一遍，效率高得多。
4.2 cwd、exe和mmap文件这些容易漏的路径
除了fd，还有几个容易被忽略的路径信息源：
- /proc/PID/cwd：进程当前工作目录。如果进程卡在一个相对路径的open操作上，fd里可能什么都没有，但cwd能告诉你它是在哪个目录下发起IO的。
- /proc/PID/exe：进程可执行文件的绝对路径。虽然和IO卡顿不一定直接相关，但确认进程是谁启动的、哪个版本，有时候能帮助关联已知bug。
- /proc/PID/maps：进程的虚拟内存映射，会列出映射的文件路径。如果一个文件是通过mmap映射进内存的，它的打开方式可能不会出现在普通的fd列表里，但maps里能看到文件路径，而且还能区分是私有映射还是共享映射。
在排查"某个文件被持续读/写导致D状态"时，maps有时候反而比fd更早暴露问题。比如一个数据库进程把所有数据文件都做了mmap，某个数据文件所在的存储设备故障后，进程访问到这个内存页时触发major fault，然后就卡在IO等待上，fd里看到的不多，maps里却明明白白列着那个文件的路径。
还有一个技巧是看进程的IO统计：/proc/PID/io。里面rchar和read_bytes的区别值得说一下，rchar是进程通过read系统调用读取的字节数，read_bytes是实际从存储设备读出的字节数，两者相差大说明命中page cache比较多。如果read_bytes一直在涨，说明它确实在实打实地读设备，这个信息和设备层iostat结合起来，能确认"卡住的是它自己"还是"整个设备都卡了"。
4.3 (deleted)标记：文件被删但进程还捏着不放手
用ls -l读fd时，如果看到路径后面带"(deleted)"，说明文件已经被unlink了，但进程仍然持有打开的文件描述符。这个情况在线上太常见了：日志文件被logrotate轮转删掉，但正在写日志的进程没重启，旧fd还指着那个已经被删除的inode。表现是df显示磁盘占用率很高，但du翻遍文件系统也找不到占用那么大空间的文件，因为空间被一个"看不见"的删除文件占着。
判断方法很简单，还是ls -l /proc/PID/fd，出现deleted标记的路径，就是它。处理办法通常是kill掉进程或者重启服务让fd释放，如果进程是D状态kill不掉，那就只能等IO恢复、进程退出或者自己关掉fd。这里也提醒一句：遇到D状态进程的fd路径带deleted时，可以先怀疑是否存在文件被删但还在写入的竞争问题，这类问题有时候会放大IO压力，进而拖出一大片D状态。
4.4 容器和mount namespace：看到的路径不是宿主机路径
到了容器时代，事情又多了一层。容器内进程看到的路径和宿主机上的绝对路径经常对不上。比如容器里看到的/data目录，实际上对应宿主机的/var/lib/docker/overlay2/abc123/merged/data。如果你直接按容器内的路径去找文件，必然找不到。
处理方法是看/proc/PID/root和/proc/PID/mountinfo。root符号链接指向的是进程所在mount namespace的根，mountinfo列出了这个进程能看到的所有挂载点。要翻译路径，可以进入/proc/PID/root目录后沿着相对路径走：
bash复制ls -l /proc/PID/root/data
这样会直接解析出宿主机视角的真实路径。如果是K8s环境，我一般会先用这个办法把容器内的路径换算成宿主机路径，再结合宿主机上的设备信息判断是不是绑定到了某个异常的持久化存储。用fd找路径、用root和mountinfo做路径换算，这套组合在容器排障里屡试不爽。
5. 一键脚本：把堆栈和路径全部打出来
5.1 脚本的设计取舍
把前面说的方法串起来，就是一个完整的诊断脚本。设计时有几个取舍想交代清楚。
第一，脚本用bash写还是python写？我选bash。原因是这套流程本质上是不断读取/proc下的文件，bash的文本处理足够，而且不依赖额外解释器，在救援环境里也能跑。
第二，判断"长时间D"用轮询采样。脚本每隔1秒扫一次/proc/pid/stat，连续扫5次，凡是每次都处于D状态的进程，才判定为"长时间D"，再输出详细信息。这个策略绕开了瞬时状态干扰，误报率低。
第三，脚本只做只读操作，不会向系统写入任何配置，不会触发sysrq。所以它是一个安全的诊断工具，可以在生产环境直接使用。
5.2 完整实现与关键注释
bash复制#!/bin/bash
# 功能：找出长时间处于D状态的进程，并打印内核堆栈和相关文件的绝对路径
# 用法：sudo ./dump_dstate.sh
# 依赖：root权限；内核开启CONFIG_STACKTRACE
THRESHOLD_LOW=5 # 最少采样次数
SLEEP_INTERVAL=1 # 每次采样间隔（秒）
declare -A state_map # 记录每个PID累计观察到D状态的次数
# 第一轮：收集所有PID的状态
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
if [ -r /proc/$pid/stat ]; then
st=$(awk '{print $3}' /proc/$pid/stat)
if [ "$st" == "D" ]; then
state_map[$pid]=1
echo "[$(date +%H:%M:%S)] PID $pid 首次观察到D状态"
fi
fi
done
for round in $(seq 2 $THRESHOLD_LOW); do
sleep $SLEEP_INTERVAL
for pid in "${!state_map[@]}"; do
if [ -r /proc/$pid/stat ]; then
st=$(awk '{print $3}' /proc/$pid/stat)
if [ "$st" == "D" ]; then
state_map[$pid]=$(( ${state_map[$pid]} + 1 ))
fi
fi
done
done
found=0
for pid in "${!state_map[@]}"; do
if [ ${state_map[$pid]} -ge $THRESHOLD_LOW ]; then
found=1
echo ""
echo "========== 长时间D状态进程: PID=$pid =========="
echo "--- 进程名 / 命令行 ---"
cat /proc/$pid/comm 2>/dev/null
tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null; echo ""
echo "--- 内核等待点(wchan) ---"
cat /proc/$pid/wchan 2>/dev/null; echo ""
echo "--- 当前系统调用 ---"
cat /proc/$pid/syscall 2>/dev/null; echo ""
echo "--- 内核堆栈 ---"
cat /proc/$pid/stack 2>/dev/null
echo "--- 打开的文件描述符及相关路径 ---"
ls -l /proc/$pid/fd 2>/dev/null
echo "--- 进程工作目录 ---"
ls -ld /proc/$pid/cwd 2>/dev/null
echo "--- mmap文件(前40条) ---"
awk '/^[0-9a-f]+-/{print $6}' /proc/$pid/maps 2>/dev/null | grep '^/' | head -40
echo ""
fi
done
if [ $found -eq 0 ]; then
echo "没有发现持续D状态的进程（阈值：连续${THRESHOLD_LOW}次采样）。"
fi
脚本的核心逻辑不复杂，但有几个地方我想特别解释一下。
/proc/PID/cmdline里的参数用空格分隔，但文件内部是'\0'分隔，所以用tr把'\0'转成空格，这样输出的命令行才可读。/proc/PID/stack需要root权限，所以脚本必须以sudo运行，不建议在生产环境直接root跑高危命令，但这个脚本只读，风险可控。采样次数和间隔可以按需调整，严格环境下可以加大采样次数，比如每2秒采一次，连续15次，能更准确确认"长时间"D状态。
5.3 跑了一遍之后：常见误报与二次确认
脚本跑完，输出里可能混着一些干扰项。这里说几个我遇到的常见情况。
第一，内核线程也会进入D状态。内核线程通常没有cmdline，没有fd目录，它会显示为方括号里的名字，比如[jbd2/sda1-8]、[kworker/u8:4]。它们本身没有用户态文件路径，但它们的D状态往往和文件系统或驱动有关，所以不能忽略。要看它们卡住的原因，只能靠内核堆栈和内核日志。
第二，某些进程可能只是瞬间D状态，但在采样轮次里恰好每次都命中。加大采样次数能缓解这个问题，但也不能完全消除。所以脚本输出的进程还要再用hung task机制交叉验证一下：查dmesg看有没有对应的hung task告警，如果内核日志里也有这个PID的记录，几乎可以实锤了。
第三，网络文件系统下的路径。如果D状态进程在访问NFS或CIFS挂载点下的文件，fd显示的路径可能指向挂载点下面的具体文件，也可能因为服务端无响应而显示不了具体文件，只能看到挂载目录本身。这种情况要结合mount输出，确认挂载参数里有没有soft或hard选项，hard挂载在服务端故障时会让进程永无止境地D下去。
6. 一次真实的D状态排查全过程
6.1 现象与第一反应
有一回线上应用突然"卡死"，业务方反馈所有请求都堵住了。我登上服务器，top看到load已经到30，CPU空闲，wa在95%左右，一大片D状态进程。初步判断是存储IO问题，但机器上有本地磁盘、有远端存储，还有NFS挂载的共享目录，一时说不准是哪个设备。
先用vmstat确认：r列为0，b列长期在十几以上，说明阻塞进程很多，IO等待问题板上钉钉。接着iostat -x 1发现本地sda基本没读写，sdb也没有活动，但NFS挂载点对应的设备路径根本不在iostat列表里。我意识到问题可能出在NFS上。
6.2 从堆栈到路径的推导
按前面的方法，用ps筛选出卡住的进程，然后逐个读堆栈。markdown输出里我印象很深的是这样一个堆栈：
text复制[<0>] nfs4_do_open+0x1f7/0x220
[<0>] nfs4_atomic_open+0x5e/0x190
[<0>] nfs_open+0x54/0x90
[<0>] path_openat+0x8d/0x300
[<0>] do_filp_open+0x3b/0xa0
[<0>] do_sys_open+0x121/0x210
...
堆栈里连续好几个nfs函数，说明它正卡在NFS协议的open流程中，往深了说是等NFS服务端的响应。再用ls -l /proc/PID/fd一看，几乎每个卡住的进程都有fd指向同一个目录：/mnt/share/xxx。路径和堆栈互相印证，结论已经非常清楚——问题不是本地盘，而是NFS挂载目录这个共享存储通道出了状况。
当时我还随手读了/proc/PID/io，发现rchar和read_bytes都不算高，因为open阶段还没到真正大量读数据的时候，这进一步证明是握手阶段就堵住了，而不是数据吞吐打满。这个细节让后续沟通变得非常简单，直接拿堆栈给存储团队看就行。
6.3 根因与处理结果
进一步查NFS服务端状态，发现服务端因为硬件维护导致网络短暂中断，但客户端挂载参数用了hard和bg，没有配置soft超时，所以进程进入D状态后就一直傻等，既报不了错也不会自动重连快速失败。NFS服务恢复后，D状态进程陆续退出，业务也随之恢复。整个过程里，如果只盯着load和wa，可能折腾半天还不知道问题在哪；一旦把堆栈和文件路径打出来，两分钟就锁定了是NFS共享目录的问题。
这次之后我做了一个调整：把NFS挂载参数改成hard加timeo和retrans的细化配置，并且在监控里补了一条自定义指标，定期检查进程的wchan，一旦发现大量进程停在rpc_wait_bit_killable或nfs相关函数上，立刻报警。这套从堆栈出发的监控思路，比单纯看iowait要灵敏得多。
排查D状态问题，说到底就是问三个问题：谁在等、等什么、等的文件在哪。谁能把这三个问题回答清楚，谁就能在别人还在看top截图的时候，直接把问题钉死在子系统和文件路径上。上面这套方法我用了很久，从裸机到容器环境都验证过，希望也能帮你少走几次弯路。