Linux命令实战：从故障场景到排查链路全解析-代码聚汇网

Linux命令实战：从故障场景到排查链路全解析

清浅池塘·2026-09-04·阅读 82 GEO检测（免费）

Linux命令故障排查CPU负载

|难度：普通|阅读约 48 分钟

上午刚处理完一个线上告警，回工位路上我脑子里一直转着一句话：不少同事问我"Linux 命令到底怎么记"，其实真正该问的是"遇到这个业务场景，我该从哪条命令下手"。命令背得再多，不会串成排查链路，到了服务器上照样抓瞎。这篇不打算做命令大全式的罗列，而是把我在业务服务器上高频用到的 Linux 命令，按真实故障和日常运维场景重新捋一遍。无论你是刚接手服务器的后端开发，还是长期跟 Linux 打交道的运维工程师，甚至只是自己买了台云主机在折腾个人项目，这套思路应该都能直接抄作业。

1. 一切从"卡"开始：CPU和内存该看哪些指标才算看对

业务反馈最多的第一句话通常是："服务器卡了""接口好慢""机器是不是又出问题了"。这时候别急着重启，也别一上来就盯着某个命令的输出当圣旨。先把问题范围缩小到 CPU、内存、磁盘 IO 这三类，再决定下一步怎么查。

1.1 uptime和load average的真正读法

登录服务器后我会先敲 uptime：

bash复制uptime
# 输出示例
 10:22:31 up 68 days,  4:12,  3 users,  load average: 8.61, 6.32, 4.05

load average 后面三个数分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。很多新手一听"平均负载高就是 CPU 满"，这个判断不够准确。负载本质上是处于可运行状态和不可中断睡眠状态的进程平均数，它既包含正在 CPU 上跑的进程，也包含等待 IO 的进程。

所以看到 8.61 这个数字，第一反应应该是：机器逻辑核数是多少？可以用 nproc 查。如果是 8 核机器，负载 8.61 意味着队列已经略超核数，需要警惕；如果是 32 核机器，负载 8 其实相当闲。同一个数字在不同机器上含义完全不同，这也是我为什么反对把负载阈值写死在监控脚本里。

另外，如果 1 分钟负载很高但 15 分钟很低，说明是刚刚发生的突发状况，很可能是某个定时任务或者大批量请求突然进来；反之如果三个数都高，说明问题已经持续一段时间了，不是临时抖动。

1.2 vmstat按秒看趋势，而不是看一张截图

uptime 只能告诉我"现在很忙"，但要判断忙在 CPU 还是忙在磁盘 IO，下一步我会执行：

bash复制vmstat 1 5

输出大致长这样：

text复制procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 6  0      0 1856233  38012 4192820    0    0   112    65 1582 3219 63 12 22  3
 7  0      0 1845102  38012 4193100    0    0  1210    32 2136 4012 78  9 12  1

逐列看关键项：

r：运行队列中的进程数。如果长期大于 CPU 核数，CPU 大概率不够用。
b：不可中断睡眠的进程数。这里通常是被磁盘 IO 卡住，如果 b 经常大于 0，说明磁盘响应很慢。
us / sy：用户态和内核态 CPU 占用。sy 偏高时，要考虑是不是系统调用太频繁，比如大量网络小包、频繁上下文切换。
wa：CPU 等待 IO 完成的时间占比。wa 高时，CPU 在干等磁盘，这时候加 CPU 没用，得查磁盘。
si / so：换入换出内存。这两个长期非零，说明内存严重不足，系统在频繁用磁盘充当内存。
cs：上下文切换次数。如果 cs 非常高，可能是线程数量过多或者锁竞争严重。

vmstat 一定要看一段时间内的趋势，比如 vmstat 1 10，隔 1 秒打一次打 10 次。只看一次输出经常会把瞬时抖动当故障，等到下一次再抓可能已经恢复了。如果 wa 长期高于 20%，再配合 iostat -x 1 5 去看具体磁盘的 %util 和 await，判断是磁盘硬件性能到瓶颈，还是某个进程在乱写日志。iostat 属于 sysstat 包，有些精简系统没有装，可以先用 yum install sysstat 或 apt install sysstat 补上。

1.3 top与pidstat：从进程到线程定位消耗源

vmstat 定位了大方向之后，要找出具体是哪个进程在消耗资源，就用 top：

bash复制top

进去后按 P 按 CPU 排序，按 M 按内存排序，按 E 切换内存显示单位。很多人习惯打开 top 截个图就完事，其实 top 更有用的动作是按 1 展开每个 CPU 核的使用率，看看是不是只有某一个核被打满，其他核都在闲着——这种情况常见于单线程应用，比如部分旧版 Redis 或 Node.js 单线程模型，加机器不一定解决，要看应用本身能不能多线程。

更精确的做法是用 pidstat 按进程和线程拆分：

bash复制pidstat -u -p 1234 1 5
pidstat -t -p 1234 1 5

-t 能看到进程内部各线程的 CPU 占用。比如 Java 应用某个线程 CPU 飙高，拿到线程 PID 后 printf '%x\n' 线程PID 转成十六进制，再对到 jstack 输出里的 nid=0x...，就能直接定位到代码里的哪一段线程逻辑在空转。这个套路我在排查线上"GC 线程狂转"和"业务线程死循环"时用了很多次，比瞎猜日志高效得多。

1.4 free和/proc/meminfo：别把cache误判成内存泄漏

内存排查最容易踩的坑就是看 free -m 的 used 列很高就以为内存不足。

bash复制free -h

关键要看 available 而不是 used。Linux 会把空闲内存尽量用作 page cache，用于缓存磁盘文件，这部分内存在应用需要时是可以回收的，所以 used 里包含了大量 cache 并不代表真的不够用。可用内存的准确口径是 available 这一列，它已经扣除了系统估计不可回收的部分。

如果实在想知道某个应用占了多少内存，不要只看 ps aux 里的 RSS，因为 RSS 包含了共享库重复计算的量。更接近实际的是：

bash复制ps -eo pid,rss,vsz,cmd --sort=-rss | head -20

RSS 单位是 KB，要读成 GB 就除以 1024 再除以 1024。如果出现进程无故消失或者被杀，去查内核日志里有没有 OOM 记录：

bash复制dmesg -T | grep -i out.of.memory
grep -i oom /var/log/messages

一旦确认是 OOM，单纯加大内存只是缓解，建议先查清楚是哪个进程触发，再看是不是该调 JVM 堆参数、限制单个进程内存，或者给系统配置 swap 空间。swap 能兜底但别指望它能救命，频繁 swap 比内存不足更伤性能。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 磁盘告警从df开始，但不能从df结束

磁盘告警应该是最常见的监控项了。相比 CPU 和内存，磁盘问题的排查链路更长，因为根因往往不在"当前目录占了多少"，而在一些看不见的地方。