服务器卡了，老板问你为什么，你说"我看看"，然后敲了一堆命令，最后还是不知道问题在哪——这个场景是不是很熟？
本文把常用的排查思路和命令整理成一套可复用的剧本。从最基础的 top/free/iostat/ss 四件套，到进阶的 perf、strace、火焰图，按"先定方向、再选工具、读图定位、交叉验证"的顺序讲清楚。下次遇到性能问题，照着这个套路来。
一、排查思路
性能问题无非四大资源：
CPU → 计算能力不够
内存 → 空间不够，频繁换页
磁盘 → IO 太慢，读写阻塞
网络 → 带宽满了，连接数爆了
排查顺序：先看整体，再定位具体。
1. top/htop → 整体概览
2. 定位瓶颈 → CPU/内存/磁盘/网络
3. 找到进程 → 哪个进程在搞事
4. 深入分析 → 为什么这个进程有问题
5. 解决问题 → 优化/重启/扩容
关键认知："慢"不等于"CPU 满"。top 里 %CPU 不高，延迟可能耗在磁盘 IO 等待、内存换页，或卡在某个网络 syscall 上。方向判错，后面都是白调。
二、基础四件套（先定方向）
2.1 CPU / 负载
top -b -n 1 | head -20
mpstat 1 3 # 看每核，重点盯 %iowait
load average 怎么看：
单核：load < 1 正常，= 1 满载，> 1 过载
多核（4核）：load < 4 正常
简单算法：load / CPU核数 < 0.7 是健康的
2.2 内存（看 available，别只看 free）
free -h
vmstat 1 5
free 很小没关系，Linux 会用空闲内存做 cache
available 才是真正可用的内存
available < 总内存 10% → 危险
Swap used > 0 → 内存已经不够用了
vmstat 的 si/so > 0 → 正在换页
2.3 磁盘
iostat -x 1 5
%util > 70% → 磁盘忙
await > 10ms → 响应慢
iotop -o → 看 IO 最高的进程
2.4 网络
ss -s
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
TIME-WAIT 过多：sysctl -w net.ipv4.tcp_tw_reuse=1
CLOSE-WAIT 过多：代码没正确关闭连接（socket/http 没 close）
三、进阶三剑客：perf / strace / 火焰图
基础四件套能"定方向"，但要"钉死根因"，得靠进阶工具。
| 工具 | 擅长 | 看什么 |
|---|---|---|
| perf | CPU 热点、内核态开销（on-CPU） | 哪个函数最占 CPU |
| strace | 系统调用级追踪 | 进程卡在哪个 syscall |
| 火焰图 | 把 perf 采样可视化 | 时间花在哪条调用栈 |
3.1 CPU 瓶颈：perf 抓热点
# 安装（perf 版本最好与内核一致）
apt install -y linux-tools-common linux-tools-$(uname -r) strace
# 系统范围采样 30s，-F 99 是惯例频率（避开整百共振）
perf record -F 99 -ag -- sleep 30
perf report # 交互式看热点
perf top -p $PID # 实时看热点函数
# 生成火焰图（需 FlameGraph 脚本）
perf script | stackcollapse-perf.pl | flamegraph.pl > cpu.svg
火焰图读法：横轴是采样总量（越宽越占 CPU），纵轴是调用栈深度，最宽的栈就是最耗 CPU 的路径。
3.2 内存瓶颈：别只看 free
perf stat -e cache-misses,cache-references,page-faults,major-faults \
-p $PID -- sleep 10
free -h && vmstat 1 5
cat /proc/meminfo
major-faults（需从磁盘换入的缺页）偏高 → 内存压力已逼出 IO；cache-misses 高 → 热点数据没留在 CPU 缓存。
3.3 IO 瓶颈：strace 看卡在哪个调用
strace -Ttt -e trace=file,network -f -p $PID # 逐条看耗时
strace -c -f -p $PID -- sleep 5 # 汇总统计
iostat -x 1 && pidstat -d 1 # 系统级印证
strace -Ttt -e trace=file,network -f -p $PID # 逐条看耗时
strace -c -f -p $PID -- sleep 5 # 汇总统计
iostat -x 1 && pidstat -d 1 # 系统级印证
-T 标出的高耗时 read/write/connect 就是阻塞点。某 connect 每次几百毫秒 → 问题大概率在下游/网络。
四、综合实战：接口变慢的端到端排查
场景：某在线接口 P99 时延突增，目标 30 分钟内给出根因方向（改代码 / 调参数 / 扩容）。
# 1) 定方向
top -b -n 1 | head -20 && mpstat 1 3
# 2) CPU 热点 + 火焰图
perf record -F 99 -ag -p $PID -- sleep 20
perf script | stackcollapse-perf.pl | flamegraph.pl > cpu.svg
# 3) syscall 层
strace -Ttt -e trace=file,network -f -p $PID -- sleep 5
# 4) 内存 / 缓存
perf stat -e cache-misses,page-faults -p $PID -- sleep 10
free -h && vmstat 1 5
典型结论：
- 火焰图最宽栈是某个序列化函数 → 改代码优化；
strace显示connect高耗时 → 排查下游/网络；vmstat的si/so不为 0 → 加内存或查泄漏。
五、避坑与最佳实践
- strace 通过 ptrace 显著拖慢目标进程：生产慎用、避免长时间 attach；统计优先用
-c，拿完数据立刻退出。 - perf 采样频率并非越高越好：
-F 99是惯例，过高会放大自身开销、干扰结果。 - 火焰图只看 on-CPU 时间：进程若卡在 IO/锁（off-CPU），火焰图会"看起来很干净"，需用 off-CPU 火焰图（perf sched / eBPF），否则漏判。
- 权限约束：
cat /proc/sys/kernel/perf_event_paranoid默认多为 2~4，内核态/整机数据需CAP_PERFMON/CAP_SYS_ADMIN；容器内需放开 securityContext。 - 采样要覆盖真实业务高峰，别把偶发抖动当稳定根因。
六、常用命令速查
# CPU
top / htop # 整体概览
mpstat -P ALL 1 # 每核
perf top -p $PID # 实时热点
perf record -F 99 -ag # 采样
# 内存
free -h # 内存概览
vmstat 1 # 内存统计
perf stat -e page-faults -p $PID
# 磁盘
df -h # 磁盘空间
iostat -x 1 # 磁盘 IO
iotop -o # IO 最高进程
# 网络
ss -s # 连接统计
ss -ant # 所有 TCP 连接
iftop -i eth0 # 实时流量
七、监控告警建议（事后排查不如事前监控）
排查是事后，监控是事前。建议配置：
| 指标 | 告警阈值 |
|---|---|
| CPU 使用率 | > 80% 持续 5 分钟 |
| 内存使用率 | > 85% |
| 磁盘使用率 | > 85% |
| 磁盘 IO util | > 80% 持续 5 分钟 |
| 网络连接数 | > 50000 |
| Load Average | > CPU核数 × 2 |
常用方案：Prometheus + Grafana、Zabbix、云厂商自带监控。
总结：性能排查套路——先看整体(top) → 定位瓶颈(CPU/内存/磁盘/网络) → 找到进程(ps/top排序) → 深入分析(perf/strace/火焰图) → 解决问题。
记住几个关键命令：top/htop 看整体、iostat -x 1 看磁盘、ss -s 看网络、free -h 看内存。多练几次，下次服务器出问题就不慌了。
有问题评论区交流~