系统假死常由高%wa（i/o wait）引发，本质是cpu空等磁盘io，而非真忙；典型诱因是高nice值的io密集型进程（如rsync、dd）持续发起读写请求，导致存储栈阻塞和关键服务调度延迟。

系统“假死”常表现为响应迟滞、命令无反馈、键盘鼠标卡顿，但 top 显示 CPU 使用率却不高（比如 %us 和 %sy 都偏低），而 %wa（I/O wait）异常高——这说明 CPU 在空等磁盘或设备完成 IO，不是真忙，而是被阻塞。此时若同时存在高 nice 值（即低优先级）的 IO 密集型进程，它虽不抢 CPU 时间，却会持续发起大量读写请求，拖慢整个存储栈，间接导致其他关键进程（如 SSH、桌面服务）调度延迟，形成“假死”感。

确认是否为 IO 密集型进程引发的假死

先快速判断问题性质：

• 运行 top，观察右上角 Cpu(s) 行：若 %wa > 20% 且持续不降，基本锁定是 I/O 瓶颈；
• 按 Shift+P 按 CPU 占用排序，再按 Shift+T 按运行时间排序——真正耗时的可能不是 CPU 高的进程，而是那些 %CPU 很低但 TIME+ 很长、状态为 D（不可中断睡眠）的进程，它们正卡在磁盘等待中；
• 用 iostat -x 1 查看磁盘指标：重点关注 %util（接近 100% 表示磁盘饱和）、await（平均等待毫秒数，>100ms 通常异常）、r/s 和 w/s 是否突增。

识别高 nice 值的 IO 进程（易被忽略的“老实人”）

IO 密集型任务往往被用户主动设为高 nice 值（比如 nice -n 15 rsync ...），本意是“谦让”，但它仍会高频触发内核 IO 调度、页缓存回收、上下文切换等开销。这类进程在 top 中 %CPU 很低，容易被忽视：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 在 top 中按 f 进入字段管理，启用显示 NI（Nice 值）和 STATE 列；
• 按 Shift+N 对 NI 列升序排序（数值大的排前面，如 15、19），重点检查那些状态为 D 或 R、命令含 dd、tar、rsync、find -exec、gzip 的进程；
• 用命令批量筛查：ps -eo pid,ni,comm,state,cmd --sort=-ni | grep -E "(D|R).*[rR][sS][yY][nN][cC]|[dD][dD]|[tT][aA][rR]" | head -10。

临时缓解：降低其 IO 影响，而非只调 CPU 优先级

单纯用 renice 把它调到 19 并不能解决假死——它还是在疯狂发 IO 请求。更有效的是限制它的 IO 权重或带宽：

• 查出 PID 后，用 ionice 降级其 IO 调度类：ionice -c 3 -p PID（-c 3 是 idle 类，仅在磁盘空闲时才执行 IO，对前台响应几乎零干扰）；
• 若需精细控制，配合 cgroup v2 限速（推荐）：
  sudo mkdir -p /sys/fs/cgroup/io-throttle
echo $$ | sudo tee /sys/fs/cgroup/io-throttle/cgroup.procs
echo "8:0 wbps=max,rbps=max" | sudo tee /sys/fs/cgroup/io-throttle/io.max（先允许，再按需设具体值，如 rbps=10485760 限读 10MB/s）；
• 紧急时直接暂停：kill -STOP PID，确认系统恢复后再 kill -CONT PID 或终止。

长期预防：合理设置 nice + ionice + 资源隔离

避免同类问题复发，关键在启动阶段就做约束：

• 后台批量任务统一用组合命令启动：nice -n 12 ionice -c 2 -n 6 tar -cf backup.tar /data（CPU 谦让 + IO best-effort 中等优先）；
• 对定时任务（cron），在脚本开头加：ionice -c 3 nice -n 19 your-command；
• 生产服务（如数据库备份脚本）建议绑定到独立 cgroup，并配置 cpu.weight 和 io.weight，防止单个任务拖垮整机。