CPU 明明不高，服务器却卡顿：先查这三处

服务器卡了，第一反应是看 CPU 使用率。结果 top 一看，CPU 才用了 30%，负载却很高，请求响应慢得离谱。这时候盯着 CPU 找问题是找错了方向：CPU 不高只说明处理器不忙，卡顿的瓶颈往往在 CPU 之外。先查下面三处，大多数情况十分钟内能定位。

第一处，看平均负载和等待状态。uptime 或者 top 第一行的 load average 如果远高于 CPU 核数，说明有大量进程在排队。关键要看 top 里 %wa 这一列：它是 CPU 花在等待磁盘 I/O 上的时间占比。如果 %wa 长期超过 20%，问题不在计算，而在磁盘。常见的元凶是慢盘、日志狂写、或者某个进程在不停地刷盘。用 iostat -x 1 看一眼 await（平均等待毫秒数）和 %util：await 超过几十毫秒、%util 接近 100%，磁盘就是瓶颈。这时该做的是把写日志的频率降下来、把热数据挪到更快的盘上，或者给数据库加缓存，而不是给机器加核。

第二处，看内存是不是在悄悄换页。free -h 显示的剩余内存可能不少，但要看 si 和 so 这两列（vmstat 1 里也能看到）：它们是每秒换入换出的内存页数量。只要 si、so 持续大于 0，系统就在用磁盘当内存使，速度会断崖式下跌。更隐蔽的一种情况是内存够用，但系统把大量内存分给了文件缓存，应用一要内存就得先回收缓存，回收的过程也会卡。排查时先看 free 的 available 一栏，那才是应用真正能用的内存；再看 dmesg 里有没有 OOM Killer 的记录——有时候某个进程已经被系统悄悄杀掉又被拉起，服务表现为间歇性卡顿，日志里却只有一条不起眼的 killed 记录。

第三处，看网络和连接数是不是到顶了。服务本身不卡，但请求进不来，也会表现为整体卡顿。ss -s 可以快速看当前连接总数，ss -tan | grep -c TIME-WAIT 看 TIME-WAIT 的堆积量。短连接打得太猛时，TIME-WAIT 会占满本地端口，新连接建不起来，表现就是偶发超时、时好时坏。另一类是文件描述符耗尽：cat /proc/<pid>/limits 看 Max open files，再对照 ls /proc/<pid>/fd | wc -l 看实际用量。用到上限时，新连接直接被拒绝，日志里通常只有一句 Too many open files。这类问题加 CPU 完全没用，调大 ulimit -n 或者改用长连接才是正解。

最后说一个排查顺序，照着走基本不会绕路：先看 load 和 %wa 判断是不是磁盘在拖后腿，再看 si/so 和 available 判断内存有没有换页，最后看连接数和文件描述符判断网络层有没有到顶。CPU 使用率只是众多指标里的一个，服务器卡顿的时候，它不高恰恰说明瓶颈在别处。把力气花在真正卡住的那一环上，比盲目升级配置管用得多。