这是 codigger 昨天（2026-09-20 14:42）发布在博客园的 Linux 性能排查实战指南，从基础四件套到进阶三剑客，按"先定方向、再选工具、读图定位、交叉验证"组织。[citation:55.2][citation:55.42]
---
服务器又卡了？一篇讲透 Linux 性能排查（基础四件套 + perf/strace/火焰图）
一、排查思路
性能问题无非四大资源：[citation:55.42]
CPU → 计算能力不够
内存 → 空间不够，频繁换页
磁盘 → IO 太慢，读写阻塞
网络 → 带宽满了，连接数爆了
排查顺序：先看整体，再定位具体。
① top/htop → 整体概览
② 定位瓶颈 → CPU / 内存 / 磁盘 / 网络
③ 找到进程 → 哪个进程在搞事
④ 深入分析 → 为什么这个进程有问题
⑤ 解决问题 → 优化 / 重启 / 扩容
关键认知："慢"不等于"CPU 满"。top 里 %CPU 不高，延迟可能耗在磁盘 IO 等待、内存换页，或卡在某个网络 syscall 上。方向判错，后面都是白调。[citation:55.42]
---
二、基础四件套
2.1 CPU / 负载
top -b -n 1 | head -20
mpstat -P ALL 1 3 # 看每核，重点盯 %iowait
load average 的正确判读：
单核：load < 1 正常，= 1 满载，> 1 过载
多核（4核）：load < 4 正常
简单算法：load / CPU核数 < 0.7 是健康的
2.2 内存（看 available，别只看 free）
free -h # 看 available 列
vmstat 1 5 # 看 si/so 换页
关键原则：[citation:55.42]
free 很小没关系——Linux 会用空闲内存做 cache
available 才是真正可用的内存
available < 总内存 10% → 危险
Swap used > 0 → 内存已经不够用了
vmstat 的 si/so > 0 → 正在换页
2.3 磁盘
iostat -x 1 5 # 磁盘 IO
iotop -o # 看 IO 最高的进程
| 指标 | 阈值 | 含义 |
|:----|:----:|------|
| %util | > 70% | 磁盘忙 |
| await | > 10ms | 响应慢 |
2.4 网络
ss -s # 连接统计
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
常见问题：
TIME-WAIT 过多：sysctl -w net.ipv4.tcptwreuse=1
CLOSE-WAIT 过多：代码没正确关闭连接（socket/http 没 close）
---
三、进阶三剑客
基础四件套能"定方向"，但要"钉死根因"，得靠下面这三个：[citation:55.42]
| 工具 | 擅长看什么 | 适用场景 |
|:----:|:----------:|---------|
| perf | CPU 热点、内核态开销（on-CPU） | 哪个函数最占 CPU |
| strace | 系统调用级追踪 | 进程卡在哪个 syscall |
| 火焰图 | 把 perf 采样可视化 | 时间花在哪条调用栈 |
3.1 CPU 瓶颈：perf 抓热点
安装（perf 版本最好与内核一致）
apt install -y linux-tools-common linux-tools-$(uname -r)
系统范围采样 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 的路径。[citation:55.42]
3.2 内存瓶颈：别只看 free
perf stat -e cache-misses,cache-references,page-faults,major-faults \
-p $PID -- sleep 10
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
-T 标出的高耗时 read / write / connect 就是阻塞点。某个 connect 每次几百毫秒 → 问题大概率在下游/网络。[citation:55.42]
---
四、综合实战：接口变慢
场景：某在线接口 P99 时延突增，目标 30 分钟内给出根因方向。[citation:55.42]
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 显著拖慢目标进程 | 生产慎用，统计优先用 -c，拿完数据立刻退出 |
| perf 采样频率不是越高越好 | -F 99 是惯例，过高会放大自身开销 |
| 火焰图只看 on-CPU 时间 | 进程卡在 IO/锁上时火焰图会"看起来很干净"，需用 off-CPU 火焰图 |
| 权限不够 | 默认 perfeventparanoid 多为 2~4，需要 CAPPERFMON / CAPSYS_ADMIN |
| 采样覆盖不足 | 要覆盖真实业务高峰，别把偶发抖动当稳定根因 |
---
六、速查表
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 # 实时流量
---
七、一句话总结
性能排查的套路：先看整体（top）→ 定位瓶颈（CPU/内存/磁盘/网络）→ 找到进程（ps/top排序）→ 深入分析（perf/strace/火焰图）→ 解决问题。 事后排查不如事前监控——CPU > 80%、内存 > 85%、磁盘 util > 80%、Load Average > CPU核数 × 2，这些阈值应该提前配好告警。[citation:55.42]
发布评论