%util持续100%说明磁盘I/O饱和，CPU空闲是因等待磁盘响应；需用iostat -x 1 3验证%util与await是否同步高位，再结合iotop定位高IO进程，并检查硬件健康、调度器配置及文件系统异常。
当Linux服务器响应变慢、业务接口超时，而top里CPU空闲、内存充足，却看到iostat输出中某块磁盘的%util持续显示100%，这说明系统正被磁盘I/O死死卡住，不是CPU没干活，而是CPU在等磁盘——它已经排满队、动不了了。
确认是否真为%util 100%瓶颈
先别急着杀进程，用iostat验证真实状态：执行iostat -x 1 3，连续采样3次，重点关注%util和await两列。若某设备（如sdb或nvme0n1）%util稳定在98%～100%，且await > 50ms，基本可判定是IO饱和而非瞬时抖动。注意：SSD上%util=100%不等于硬件故障，但avgqu-sz > 4且持续上升，就说明请求已在内核队列里堆叠，必须立刻干预。
定位高IO进程：iotop是第一把刀
方法一：实时盯梢活跃IO进程
直接运行sudo iotop -o，只显示正在执行I/O的进程。观察IO>列数值，单位是KB/s；数值越大，对磁盘压力越直接。按P键可按IO使用率倒序排列，排在最顶的进程就是当前罪魁。
方法二：抓快照比对异常波动
执行sudo iotop -b -n 1 -P获取单次静默输出，再配合ps -p PID -o pid,comm,user,etime查该进程启动时间与命令名。特别注意那些etime很短（刚启动几分钟）但IO极高的进程——很可能是临时脚本、日志轮转或备份任务失控。
方法三：结合PID反查完整调用链
拿到高IO进程PID后，用cat /proc/PID/stack看其内核态堆栈。若出现大量blk_mq_do_dispatch_sched或__generic_file_write_iter，说明它正密集刷盘；若堆栈停在ext4_da_write_pages，大概率是ext4延迟分配触发了突发写入。
区分三类%util打满的真实成因
第一步：看await与%util组合形态
① 若%util≈100%但await ：磁盘本身响应快，只是并发请求太多，调度器已满负荷吞吐——问题在上层应用或IO调度策略。
② 若%util≈100%且await > 100ms：磁盘响应严重拖慢，可能是硬件故障、RAID降级、或文件系统元数据锁争抢（如大量小文件create/unlink）。
③ 若%util不高（如40%）但iowait > 30%：CPU大量时间在等IO，说明请求虽未塞满设备，但进程阻塞严重——典型如数据库redo log刷盘阻塞、或同步fsync调用过多。
第二步：检查底层设备健康与配置
运行smartctl -a /dev/sdX（机械盘）或nvme smart-log /dev/nvme0n1（NVMe盘），重点看Reallocated_Sector_Ct、Media_Errors或critical_warning字段。若这些值非零，%util打满就是硬件告警前兆，不是调优能解决的。
第三步：验证IO调度器是否错配
查看当前调度器：cat /sys/block/sdX/queue/scheduler。若设备是NVMe盘，却显示[deadline] mq-deadline none，说明内核仍用传统调度器压制了多队列优势——应强制切到none（即使用blk-mq原生调度）：echo none | sudo tee /sys/block/nvme0n1/queue/scheduler。这一步操作不可逆，重启后失效，需写入udev规则固化。
排查日志与文件系统级诱因
检查/var/log/messages或journalctl -S "2 hours ago" | grep -i "buffer I/O"，搜end_request: I/O error或EXT4-fs error。一旦发现，说明文件系统已开始丢IO，%util打满只是表象，根因是磁盘扇区损坏或连接不稳。
执行df -h确认是否磁盘空间耗尽。某些场景下，%util 100%其实是ext4在疯狂回收inode或写journal，根源却是/var/log目录被占满导致rsyslog反复重试写入失败。
用lsof +L1检查是否存在已删除但仍被进程占用的大文件（unlinked but held open）。这类文件虽不在df统计中，但其数据块仍在磁盘上被锁定，持续产生IO压力——找到对应PID后，kill -HUP PID往往能立即释放。
