很多刚接触 Linux 运维的人，一看到系统卡顿就习惯性地去加 CPU、加内存，结果钱花了问题还在。实际上，绝大多数“变慢”的锅并不在算力，而在磁盘 IO 和 系统负载。当你用 top 看到 CPU 占用并不高、但命令就是半天不返回时，基本可以断定是 IO 在拖后腿。本文就带你用三件免费又顺手的工具——iostat、vmstat、iotop——把性能瓶颈看个明明白白，最后再走一遍真实案例，让你真正会用而不是看懂。
一、先看懂负载：load average 到底代表什么
在动手之前，先得明白 uptime 或 top 里那三个数字（比如 0.50、0.80、1.20）是什么意思。它们叫 load average，分别对应过去 1 分钟、5 分钟、15 分钟的系统平均负载。对于 Linux 来说，负载包含的是正在运行和等待运行（尤其是等 IO）的进程数，而不只是 CPU 占用。所以单核机器 load 长期大于 1，或者多核机器 load 长期大于核心数，就要警惕了。如果 CPU 明明很闲、load 却居高不下，几乎一定是磁盘或网络 IO 在阻塞——这正是我们后面要抓的“元凶”。很多新手会误以为 load 高就是 CPU 不够，盲目扩容，结果新机器一上线 load 照样高，就是没分清“等 CPU”和“等 IO”的区别。
二、iostat：把磁盘 IO 看得明明白白
iostat 来自 sysstat 包，是诊断磁盘性能的首选。最常用的一句是 iostat -x 1，每隔一秒刷新一次扩展统计。重点看几列：%util 表示磁盘设备被占用的时间百分比，长期接近 100% 说明这块盘已经饱和；await 是单次 IO 平均等待时间（毫秒），数值越大越慢；r/s 和 w/s 则是每秒读写次数；rkB/s/wkB/s 是每秒读写的数据量（KB）。当你发现某个磁盘 %util 飙到 90% 以上而 await 也跟着涨，那就是典型的“磁盘打满”。如果 await 很高但 %util 不高，往往是磁盘本身响应慢或阵列降级。这和我们在 Linux 系统日志查看与分析实战：journalctl 与 /var/log 双管齐下，出事第一时间找线索 里排查应用报错是同一个思路：先定位现象，再顺藤摸瓜找根因，而不是凭感觉下结论。
三、vmstat：一屏掌握 CPU、内存、IO 全貌
相比 iostat 只盯着磁盘，vmstat 1 能在一屏里同时看到进程、内存、交换分区、IO 和 CPU。其中 bi（blocks in）和 bo（blocks out）就是每秒读写块数，能直观反映 IO 压力；si/so 是换入换出的内存页，如果这两项长期不为 0，说明物理内存不够、系统在频繁用 swap，速度自然会断崖式下跌。配合 us、sy、wa 三列（用户态、系统态、IO 等待的 CPU 占比），你可以一眼判断瓶颈在“算”还是在“等”——wa 高而 us/sy 低，基本锁定 IO；so 持续不为 0，则是内存告急。需要把分析结果定时跑出来？可以结合 Linux 定时任务 cron 完全指南：从 crontab 配置到定时备份脚本实战 把监控脚本排进计划任务，每天自动收集，免得问题发生在半夜无人察觉。
四、iotop：揪出疯狂读写的那几个进程
前两件工具告诉你“磁盘很忙”，但没说“是谁在忙”。这时候就要请出 iotop（需要 root）。运行 iotop -o 只显示正在产生 IO 的进程，按 IO 占用排序，哪个程序在疯狂读写一目了然。常见于：日志没轮转导致某个服务疯狂写盘、备份任务撞上业务高峰、或者某个 Bug 程序在死循环落盘。找到 PID 之后，再用 lsof -p PID 看看它到底在写哪个文件，问题基本就水落石出了。顺带一提，面对成堆的日志文本，Linux 文本处理三剑客 grep/sed/awk 入门实战：从日志分析到批量替换 里的技巧能帮你快速从海量输出里筛出关键行，排查效率会再上一个台阶。
五、一个真实排查案例
说个我碰到过的真实场景：一台 Web 服务器白天响应正常，每到凌晨就卡到超时。我先 uptime 看 load，发现凌晨 1 点 load 飙到 8（8 核机器）；再 vmstat 1，看到 bo 列持续几千、wa 长期 30% 以上；接着 iostat -x 1 锁定到 /data 盘 %util 100%；最后 iotop -o 抓到罪魁是 mysqld 在跑一个没加索引的报表查询，凌晨定时任务触发后全表扫描，疯狂往临时表写盘。加完索引、把报表挪到从库，load 立刻回到 1 以下。这一整套下来，从“又卡了”到“定位根因”只花了十分钟，工具就是那三件套。
六、排查思路串联：从现象到根因
把上面的链路总结一下：先用 top/uptime 看负载是否异常，再用 vmstat 1 确认是 IO 等待（wa 高）还是内存 swap（si/so 高），接着 iostat -x 1 锁定是哪块盘饱和，最后 iotop -o 揪出罪魁进程，需要的话用 lsof 看文件路径。理清这根链条，你就能从“服务器又卡了”这种模糊抱怨，变成“是 /data 盘 IO 打满，罪魁是 mysql 的慢查询在疯狂写临时表”这种精准结论。性能排查没有银弹，但工具就摆在那里，练熟这三件套，Linux 性能监控 对你来说就不再是无头苍蝇。
七、把手动排查升级成自动监控
三件套再好，也得人盯着。真要省心，可以把它们接进监控体系。比如用 nohup iostat -x 1 > /var/log/iostat.log & 把采样落盘，再用脚本定时扫描日志，发现 %util 连续超阈值就发告警邮件或推送到企业微信；也可以直接上 Prometheus + node_exporter，它内置了磁盘 IO、负载、swap 等一整套指标，配合 Grafana 画成图，哪块盘什么时候开始忙一目了然。对单机玩家来说，哪怕只是写个 cron 每天凌晨把 vmstat 和 iostat 的快照邮件发给自己，也比等用户投诉“又卡了”主动得多。工具是死的，流程是活的，把排查变成例行巡检，才是运维成熟度的分水岭。
总结一句：卡顿别急着加机器，先问一句——到底是 Linux 磁盘 IO 排查 该做的功课，还是内存、CPU 的问题？用对工具，答案几秒钟就能浮现；用错方向，砸钱也白搭。
暂无评论内容