ps中stat为d表示进程处于不可中断睡眠态，正等待磁盘或nfs io；需结合iotop -o查看实时io活动、/proc/pid/io验证read_bytes/write_bytes是否增长，并用iostat -x和dmesg交叉分析底层瓶颈，以区分健康等待与驱动/硬件卡死。
直接看 ps 的 STAT 列是 D 就说明进程卡在不可中断等待，但仅凭这个无法判断它到底在等什么、等了多久、有没有真实 IO 流量。得组合多个工具交叉验证，否则容易把驱动卡死当成正常等待。
用 ps 找出所有 D 状态进程并过滤关键字段
单纯 ps aux 输出太杂，要聚焦真正可疑的进程：
-
ps -eo pid,comm,state,pcpu,pmem,wchan,etimes --sort=-etimes | awk '$3 ~ /^D$/ {print}'：按调度延迟etimes降序，只留STATE是 D 的行；wchan显示内核等待函数名（如wait_event、__nvme_submit_cmd），比状态码更有指向性 - 避免用
grep ' D '，因为comm名里带空格或 D 字母会误匹配；必须用$3 ~ /^D$/精确匹配第三列 - 如果
wchan是-或空，说明进程已脱离调度器上下文，大概率卡在驱动或硬件层，不是应用层 IO
用 iotop 确认该进程是否真有磁盘读写行为
iotop 能看到实时 IO 量，但默认不显示纯等待无流量的进程：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 加
-o参数：sudo iotop -o—— 只显示当前有 IO 活动的进程，含刚发起请求还没返回的（即正在等响应的 D 进程） - 加
-a参数：sudo iotop -a—— 累计模式，适合查长期 IO 倾向；但注意它不反映当前阻塞状态，只看总量 - 若某进程在
ps中是 D，但在iotop -o里完全不出现，且/proc/PID/io中read_bytes/write_bytes长时间不动，基本可判定不是磁盘 IO，而是驱动/硬件卡死或 NFS 挂起
检查 /proc/PID/io 判断 IO 是否真实发生
/proc/PID/io 是最硬的证据，它记录实际落盘字节数，绕过缓存和内核中间层：
- 关注三行：
read_bytes、write_bytes、cancelled_write_bytes - 如果
read_bytes和write_bytes在几秒内无增长，而进程仍是 D 状态，说明请求没发出去或设备没响应 —— 不是“等 IO”，而是“被 IO 卡住” -
cancelled_write_bytes持续升高，往往意味着脏页反复刷盘失败（如 ext4 journal full、NFS server unreachable），此时wchan常为ext4_da_writepages或nfs_wait_bit_killable
结合 iostat 和 dmesg 定位底层瓶颈
单看进程不够，得确认是不是整个设备拖慢了：
-
iostat -x 1看%util和await：%util接近 100% 且await > 50ms时，才说明磁盘真忙；若%util很低但仍有大量 D 进程，问题不在磁盘本身 -
dmesg -T | tail -30查硬件级报错：end_request: I/O error、NVMe timeout、ataX.00: failed command这类日志一出现，基本可锁定是磁盘或控制器故障 - 对 NFS 挂载点，执行
ls /mnt/nfs若卡住，再跑showmount -e server，能快速区分是网络中断还是服务端宕机
最难的是区分“健康等待”和“卡死”。前者 read_bytes 缓慢但持续增长，await 波动但可控；后者 read_bytes 冻结、wchan 停在驱动函数、dmesg 有 timeout。这时候杀进程没用，得换磁盘、重启 NFS 客户端，或者升级对应驱动。
