磁盘队列打满会导致系统卡死，表现为命令响应极慢、ssh卡住、df/ls无反应；需用iostat -dx 1查%util≥95%、avgqu-sz>2（hdd）或>4（ssd）、await>50ms，再用sudo iotop -o定位高io进程，结合smartctl和dmesg排查硬件故障。
磁盘队列打满（即 I/O 队列积压）会导致系统卡死：命令响应极慢、SSH 登录卡住、df/ls 无反应，甚至 top 刷新延迟严重。这不是磁盘空间满，而是磁盘处理不过来请求——就像高速路口堵死，车都排到几公里外。关键要抓“谁在疯狂发 I/O 请求”和“磁盘本身是否扛得住”。
看整体磁盘负载是否爆表
先确认是不是真被 I/O 卡住：
- 运行
iostat -dx 1（需sysstat包），重点盯三项：
• %util 持续 ≥95% → 磁盘基本满负荷；
• avgqu-sz > 2（机械盘）或 > 4（SSD）→ 队列已堆积；
• await > 50ms（持续）→ 单个请求等太久，不是慢就是堵。 - 用
dstat -c -d -r -n 1同时看 CPU、磁盘读写、I/O 请求、网络，判断是否资源串扰（比如 CPU 被占满导致 I/O 处理不及时）。
揪出吃 I/O 的进程
队列满了，得知道是哪个程序在猛塞请求：
- 装
iotop（yum install iotop或apt install iotop），直接运行：
sudo iotop -o→ 只显示正在做 I/O 的进程，按 I/O 速率排序，一眼锁定“罪魁”；
sudo iotop -P→ 按进程（非线程）维度看，更清晰。 - 若
iotop不可用，用ps aux --sort=-%mem和ps aux --sort=-%cpu辅助排查：内存/ CPU 异常高的进程，往往也伴随大量刷盘（如 Java 应用 Full GC 写 swap、数据库刷 checkpoint）。
检查底层硬件与文件系统状态
队列满有时不是软件问题，而是硬件告急：
- 查磁盘健康：
sudo smartctl -a /dev/sda（把sda换成你实际磁盘名），关注Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count—— 这些值非零且上升，说明磁盘快坏了，会反复重试导致队列卡死。 - 查内核报错：
dmesg -T | tail -30，找Buffer I/O error、end_request: I/O error、ata timeout类提示，这是硬件层失败的铁证。 - 检查文件系统是否只读：
mount | grep " $(df . | tail -1 | awk '{print $1}') "，如果看到ro,（只读），说明因错误自动降级，所有写操作都会阻塞。
临时缓解与验证
定位后快速止损，再验证是否恢复：
- 对非关键高 I/O 进程，先
kill -STOP PID暂停（比kill -9安全），观察iostat队列是否回落；确认是它再决定重启或调参。 - 清空 page cache（慎用，仅临时救急）：
echo 3 | sudo tee /proc/sys/vm/drop_caches，可释放缓存压力，但治标不治本。 - 执行
sync+echo u > /proc/sysrq-trigger（需开启 sysrq），安全卸载文件系统前强制刷盘，避免二次损坏。
