金融隐士Linux 服务器卡顿、接口超时、进程被 kill、负载飙高，这些问题做运维和开发的兄弟大概率都遇到过。尤其是线上环境出问题时，那种紧张感跟救火差不多。但救火也有救火的章法，核心就是先搞清楚机器到底在“忙”什么，是 CPU 不够、内存不足、磁盘 IO 卡住，还是网络链路易堵。这篇内容我不打算堆砌命令大全文，而是把我平时排查性能问题时的真实思路和用到的常用指令整理出来，按照 CPU、内存、磁盘 IO、网络四个维度分开讲，每一步都对应实际场景，加上怎么看输出、怎么定位根因，希望能给正在被 Linux 性能问题折磨的同行一些可以直接参考的东西。
1. 性能排查入门：先判断“病在哪一科”
1.1 排查前的思路准备
很多人拿到一台卡住的服务器，第一反应就是敲 top 看一眼，然后盯着 %CPU 发呆，接着就不知道该干啥了。这种“头痛医头”的排查方式效率很低。我的习惯是，先把系统资源当成医院的分诊台，一台服务器如果出问题，无非是四大类资源排队：CPU、内存、磁盘 IO、网络。排查的第一步不是急着定位某个进程，而是先判断是哪一个资源成了瓶颈。
比如用户反馈“系统很慢”，打开终端一执行命令都觉得卡，这时候你要先判断是整机层面的资源耗尽，还是某个进程把机器拖垮了。如果是整机层面，top 里的 load average 会告诉你系统整体负载如何；如果是单进程问题，你会看到某个进程的 CPU 或内存占用异常。再比如“数据库连接超时”，你要先确认是不是网络问题，再确认是不是数据库所在机器的磁盘 IO 满了。没有这一步分类，很容易被表象带偏，抓着一个可疑进程报警，结果底层的根因是磁盘 IO 占满导致进程全部阻塞。
排查过程我建议按这个顺序走：先看负载和整体资源（top/uptime），再看明细指标（CPU/内存/IO/网络分别对应的命令），最后用日志和实时追踪工具把根因坐实。这样才能做到有据可依，而不是靠猜。
1.2 五类核心资源与对应排查工具一览
我把日常排查用到的高频指令按资源维度整理了一张表，方便出问题时快速找到该用哪把“扳手”。这张表是我实际工作中反复用到的，比背几十条命令有效得多。
| 排查维度 | 核心指令 | 解决问题 |
|---|---|---|
| 整体负载 | uptime、top |
系统负载高不高，CPU 是否饱和 |
| CPU 明细 | mpstat、pidstat |
哪个 CPU 核忙，具体哪个进程在消耗 |
| 内存 | free、vmstat、smem |
内存是否不足，是否有泄漏趋势 |
| 磁盘 IO | iostat、iotop、pidstat -d |
IO 是否饱和，瓶颈在哪个进程 |
| 网络 | ping、ss、iftop、sar -n |
连通性、端口监听、实时流量与重传 |
另外，dmesg 和 strace 是两类“杀手锏”指令。dmesg 负责看内核日志，比如 OOM 杀进程、磁盘 IO 错误，这些在现网事故里经常能抓到关键证据；strace 则用来追踪进程的系统调用，当常规指标都正常但程序行为诡异时，它能告诉我们程序到底卡在哪个系统调用上。后面我会针对每条命令展开讲怎么看输出、怎么定位问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CPU 类问题排查指令实战
2.1 第一梯队：top 与 uptime，快速锁定 CPU 压力
但凡排查性能，我的习惯都是先敲 top，再敲 uptime。uptime 输出一行就够，但信息密度很高：
bash复制$ uptime
14:32:10 up 3 days, 2:10, 1 user, load average: 4.02, 3.85, 3.20
这里最关键的是 load average 后面的三个数，分别对应 1 分钟、5 分钟、15 分钟的平均负载。怎么判断负载高不高？最简单粗暴的说法是：这个数值如果长期大于 CPU 核心数，说明 CPU 已经过载或者有大量进程在排队。比如 4 核机器，load 到 8 到 10，基本是 CPU 被打满了。如果是云服务器，可以先 nproc 看看核数。
但这里有个坑：load average 高不完全等于 CPU 忙。它统计的是处于可运行状态和不可中断睡眠状态的进程数。不可中断睡眠（D 状态）大多是因为进程在等磁盘 IO，比如 NFS 挂载盘卡了，或者本地磁盘响应缓慢。所以你会发现 load 飙到 20，但 CPU 使用率才 5%，这种畸形组合一般就是 IO 阻塞导致的。也就是说，uptime 负责“报警”，但具体“哪里着火”，还要靠 top 里的细分数据来判断。
再看 top，第一屏的 %Cpu(s) 这行有几个关键字段要会读：
us（user）：用户态 CPU 占比，常规计算逻辑主要在这里。sy（system）：内核态 CPU 占比，如果这个值常年很高，可能是有大量系统调用，或者内核资源竞争。wa（iowait）：CPU 等待 IO 完成的时间占比，偏高大概率是磁盘或网络文件系统有问题。st（steal）：虚拟机中 CPU 被宿主机抢占的时间占比，云服务器如果 st 持续很高，可能是宿主机资源争用。id（idle）：空闲占比。
单独看 us 高就是 CPU 在密集计算；sy 高可以结合 strace 确认是不是系统调用或锁竞争；wa 高则要去查磁盘。我见过很多新人一看 wa 高就以为 CPU 忙，实际上 CPU 在“干等”磁盘，真正要做的是排查磁盘 IO，而不是加 CPU 核数。
top 默认按 CPU 使用率排序，找到最耗 CPU 的进程后，记下 PID，后续用 pidstat 或 strace 继续追。如果这一秒看到的高 CPU 进程下一秒就变了，通常是频繁创建短生命周期进程导致，这时候可以留意是不是脚本在疯狂 fork。