Linux 服务器高负载排查实战：CPU、内存与磁盘监控命令详解

发布时间：2026-09-07 11:35 更新时间：2026-09-08 17:05 阅读量：5

遇到"服务器负载突然飙到十几、网站打不开"的告警，几乎是每个运维都经历过的场面，很多新手的第一反应就是重启大法，可重启之后问题往往照旧复发。要真正解决这类问题，与其靠运气，不如掌握 top、free、vmstat、iostat 这几把诊断工具，先分清瓶颈到底出在 CPU、内存还是磁盘，再对症下药，才能真正把问题连根拔起。

第一步是先看负载的整体趋势，登录后执行 uptime，它会给出三个数字，分别代表过去 1 分钟、5 分钟和 15 分钟内的运行队列平均长度。判断负载高不高必须结合 CPU 核数来解读，一台 8 核机器负载到 8 只是恰好把 CPU 用满，到 16 才算真正超载，而 2 核的小机器负载到 4 就已经明显拥塞了。负载这个数字本身也很容易误导人，因为它既可能是 CPU 在满负荷计算，也可能是大量进程堵在磁盘 I/O 的排队上，光看一个数字无法区分，所以才需要后面的工具逐层下钻。

接下来用 top 做现场勘察，它默认实时刷新进程和系统状态，也可以通过参数调整刷新间隔或只看某个指定进程。CPU 状态行里的几个数字各有含义：us 是用户态 CPU 占用，代表业务代码正在干活；sy 是内核态占用；wa 也就是 iowait，代表 CPU 干等着磁盘 I/O 完成的时间占比，如果 wa 很高而 us 不高，说明瓶颈在磁盘而不是 CPU；st 是被虚拟机管理程序"偷走"的时间，云服务器上这个值若长期偏高，通常意味着宿主机资源超卖严重，这时更换实例规格或迁移反而比在系统里调优更有效；id 则是空闲率。在进程列表里，按 P 键可以按 CPU 占用排序，按 M 键按内存排序，按数字 1 键可以展开每个 CPU 核心的占用情况，按 c 键显示完整命令行，方便看出到底是 php-fpm、MySQL 还是某个可疑进程在吃资源。看到某个进程 CPU 占用超过 100% 不用惊讶，多核服务器上单进程本就可以同时占满多个核心。真正需要警惕的是状态列为 D 的进程，它们处于不可中断睡眠状态、大多在等待磁盘 I/O，这种进程连 kill 都杀不掉，如果大量堆积，说明存储子系统已经严重过载，此时必须从 I/O 层面下手，盲目 kill -9 毫无意义。

top 反映的是瞬时快照，想看清系统的整体运行节奏，就要用到 vmstat，它可以按秒连续采样多次，输出等待运行的进程数、不可中断睡眠的进程数、swap 换入换出的量、块设备的读写块数、上下文切换与中断次数等信息。解读起来并不难：等待运行的进程数若持续高于 CPU 核数，说明 CPU 已经饱和；swap 换入换出持续非零，说明物理内存吃紧、系统正在内存与磁盘之间疲于奔命地搬运数据；块设备读写数值巨大，则说明磁盘通道非常繁忙。

当怀疑瓶颈在磁盘时，iostat 和 iotop 就是定位的利器。执行 iostat -x 可以按物理设备列出扩展统计，重点看 %util 是否接近 100%，接近就意味着设备已经饱和；再看 await 平均 I/O 响应时间是否明显超出该磁盘类型的正常范围，机械盘和 SSD 的正常值可以相差几十倍，一旦远超就说明异常；svctm 单次 I/O 服务时间也能提供参考。随后用 iotop -o 只显示当前确有 I/O 操作的进程，很快就能锁定究竟是哪个进程在大量读写。找到元凶之后，常见的对策包括给数据库加大 buffer pool、把日志目录迁到独立磁盘、清理慢查询和无索引扫描、对临时文件目录改用 tmpfs 等等。

内存问题的排查思路则完全不同。执行 free -h 时，新手常被 used 那一栏的高数值吓到，其实 Linux 的内存哲学是"闲着也是闲着"，它会大方地把空闲内存用作 page cache 来缓存文件。真正判断内存是否吃紧要看两个地方：一是 available 这一列，它代表在不触发 swap 的前提下还能分给新程序多少内存，这才是贴近真实余量的指标；二是 swap 的已用值，只有当 swap 被真正用上、尤其是换入换出持续非零时，才是内存告急的强信号。如果确认内存不足，先在 top 里按 M 排序观察各进程的 RES 是否只涨不跌，排查是否存在内存泄漏，再考虑调整 MySQL 的 innodb_buffer_pool_size、PHP 的 memory_limit 等参数，必要时才升级内存或补上 swap。

把这些工具串起来，就形成了一套可以复用的排查流程。遇到服务器卡的告警，先执行 uptime 看趋势，若 1 分钟负载远高于 15 分钟，说明是刚刚发生的突变，重点排查近期的操作或流量；若持续偏高则是常态性瓶颈，需要从架构层面解决。接着用 top 按 CPU 排序，wa 高就直奔磁盘、us 高就锁定高占用进程，必要时用 top -H 下钻到具体线程。再用 free -h 排除内存压力，用 iostat 和 iotop 定位 I/O 大户，顺手用 df -h 确认磁盘没写满、inode 没耗尽。随后回顾近期是否改过配置、上过新代码或遭遇了刷量攻击，结合 dmesg 与 /var/log 下的日志相互印证，对 php-fpm、Nginx、MySQL 等服务再看一眼各自的慢日志和访问日志，通常凶手就藏在这里。诊断工具虽然不少，核心思路始终只有一条：先分清瓶颈在 CPU、内存、磁盘还是网络，再逐层下钻定位到具体进程。最后也建议平时就把 nmon 或 sar（sysstat 包）用起来，把性能趋势数据持续记录下来，这样故障发生时才有历史基线可以对比，能准确知道异常是从哪个时间点开始的，把 sar 加进 crontab 每小时自动采集一次，关键时刻价值千金。

继续阅读