服务器突然变卡，CPU 却不高？先看 iowait 和磁盘

朋友，前两天半夜被一条报警短信吵醒：业务接口的响应时间从 50 毫秒飙到了 3 秒。第一反应是 CPU 被打爆了，结果 top 一看，CPU 才用了两成，内存也还够。那机器到底在忙什么？答案藏在 top 右上角一个不起眼的数字里：wa，也就是 iowait。

iowait 是什么意思呢？简单说，CPU 有空，但它在等磁盘。进程发起了读写请求，磁盘还没回，CPU 只能干等，这段时间就被记成 iowait。wa 长期超过 20%，基本可以断定磁盘就是瓶颈，这时候加 CPU、加内存都没用，方向就错了。

排查分三步走。第一步，top 看 %wa，再按 1 看看各核是不是都在等 IO，顺手用 vmstat 1 看看 bi、bo 两列，读写量大不大。第二步，iostat -x 1，重点看 %util 和 await：%util 接近 100%，说明磁盘已经跑满了；await 很大，说明每次 IO 都在排队。第三步，iotop -o 直接揪出真凶，哪个进程在疯狂读写，一目了然。

我遇到过几次典型情况，跟你对一下：日志没做轮转，某个服务一晚上写了几十个 G；定时备份和业务高峰撞了车；数据库少了索引，一条慢查询把磁盘读满；还有云盘本身的性能到了上限。止血的办法也一一对应：先给日志做轮转、把备份挪到凌晨低峰、给慢查询加索引。

长期来看，治本就三件事：一是日志和数据分盘，别让日志跟数据抢同一块盘；二是把 %util 和 await 接进监控，设个阈值报警，别等用户投诉了才发现；三是按业务量选云盘的性能规格，普通盘扛不住就升一级。

最后提醒两句：遇到卡顿别一上来就重启，重启只能清掉内存里的脏数据，磁盘瓶颈还在，下次高峰照样卡；也别急着升级 CPU，wa 高的时候 CPU 是闲着的，加了也白加。下次服务器再变卡，先看一眼 wa，十秒就能找到方向。