磁盘I/O瓶颈是更新失败且服务器卡死的常见原因，表现为top中%wa高、大量D状态进程、iostat显示util>90%及await异常、iotop定位高IO进程，以及df和smartctl揭示空间不足或磁盘故障。
更新失败且服务器卡死，常见原因之一是磁盘 i/o 瓶颈。此时系统看似“没响应”，实则是大量进程卡在不可中断睡眠（d 状态），等待磁盘完成读写。排查不能只看表面，要分层验证、快速定位。
看 top 里的 %wa 和 D 状态进程
执行 top -c，重点关注两处：
- %wa（I/O wait）值：超过 30% 就说明 CPU 大量时间在等磁盘，不是 CPU 真忙；
- 进程状态列（STAT）：出现大量 D（uninterruptible sleep）进程，尤其是包管理器（如 yum、apt、dnf）、数据库或日志服务，基本可锁定为 I/O 阻塞；
- load average 明显高于 CPU 核心数，但 us/sy 却很低——这是典型的 I/O 型卡顿特征。
用 iostat 确认磁盘是否打满
运行 iostat -x 1 5，观察关键指标：
Handsfree Windows Control
下载
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
- util > 90%：设备利用率饱和，磁盘已无余力处理新请求；
- await > 50ms（SSD）或 > 100ms（HDD）：单次 I/O 平均等待时间过长，说明队列堆积严重；
- avgqu-sz > 2：平均队列长度持续大于 1，表示请求排队中；
- 对比 r/s 与 w/s：若更新期间 w/s 暴增（如从几十飙到上千），大概率是软件包解压、数据库重放、日志刷盘等写密集操作触发了瓶颈。
用 iotop 找出“真凶”进程
执行 sudo iotop -oP（只显示实际在做 I/O 的进程）：
- 重点关注 IO> 列数值大的进程，尤其是 WRITE 高的；
- 常见元凶包括：dpkg（Debian/Ubuntu 更新）、rpm 或 dnf（RHEL/CentOS）、mysqld（binlog 或 redo log 刷盘）、rsyslogd 或 journald（日志批量落盘）；
- 若看到某个进程 IO> 占比长期超 80%，且 SWAPIN 列也有值，说明它可能同时在触发内存换页，加剧 I/O 压力。
检查磁盘空间和健康度
空间不足或硬件异常会直接导致 I/O 报错并卡死：
- 运行 df -h：确认 /、/var、/boot 是否使用率 ≥95%，尤其 /var/cache（yum/dnf 缓存）和 /var/lib/rpm（RPM 数据库）；
- 运行 dmesg | grep -i "buffer\|io\|sdx\|medium"：查找 Buffer I/O error on device sdx、Medium Error 等关键词，提示磁盘物理故障；
- 对疑似故障盘执行 sudo smartctl -a /dev/sdx，检查 Reallocated_Sector_Ct、Current_Pending_Sector 是否非零，以及 SMART overall-health self-assessment test result: FAILED。
