2、性能分析工具入门：perf、top、vmstat、sar等
说起来，刚入行那会儿我总觉得“调优”是个玄学。CPU高、内存爆，无非就是重启大法。后来有一次线上服务半夜告警，CPU跑满100%，我愣是盯着裸进程列表看了半小时，什么也看不出来。从那以后，我开始老老实实和这几个工具打交道。
其实性能调优的核心就一句话：先找证据，再下结论。下面这几个工具，就是我平时最常用的“证据收集器”。
2.1 top——最直接的“体检报告”
top是Linux下最基础的性能监控命令。你只要敲一下回车，就能看到系统当前的“生命体征”。我个人习惯第一眼先看load average——如果三个数值都超过了CPU核数，说明系统已经忙不过来了。
2.2 vmstat——虚拟机还是虚？其实看的是系统整体
vmstat这个名字容易让人误会，以为它只看虚拟内存。其实它报告的是系统全局的进程、内存、分页、块IO、中断和CPU信息。我特别喜欢它的连续采样能力：
vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 6543212 1234 567890 0 0 1 1 45 67 12 3 85 0 0
重点看三列：
- r（运行队列）——如果这个值长期大于CPU核数，说明CPU不够用了
- us（用户态CPU） + sy（内核态CPU）——加起来超过90%就要警惕
- wa（IO等待）——高wa往往是磁盘先扛不住了
2.3 sar——系统活动记录仪，查历史比翻旧账还方便
sar是sysstat包的核心工具。它不仅能看实时数据，更重要的是可以回看历史记录。我遇到疑难杂症时，第一步就是去查/var/log/sysstat/下的历史sar文件，看看问题发生的前后系统到底经历了什么。
常用三板斧：
| 命令 | 看什么 | 我常用的场景 |
|---|---|---|
sar -u 1 3 | CPU使用率（us/sy/id/wa等） | 排查CPU飙高 |
sar -r 1 3 | 内存使用（kbmemfree/kbmemused） | 看是不是内存泄漏 |
sar -n DEV 1 3 | 网卡流量（rxpck/s, txpck/s） | 判断网络是否打满 |
2.4 perf——性能事件的“显微镜”
perf是Linux内核自带的性能剖析工具。如果说top是医院门口的量血压机器，那perf就是CT机。它能精确告诉你CPU在哪个函数、哪行代码里花了多少时间。
我最常用的两个操作：
perf top——实时显示当前系统最热的函数，比top看到的进程粒度更细perf record / perf report——采样并生成火焰图的数据源
perf top一看，排在榜首的居然是do_sys_open——也就是频繁打开文件。后来发现代码里每次请求都要读配置文件，改成缓存后问题瞬间解决。
perf_event_paranoid设成1，这样普通用户也能用perf采样。命令是echo 1 | sudo tee /proc/sys/kernel/perf_event_paranoid。如果不设，非root用户用起来会很受限。
2.5 工具使用对比速查
这几个工具各有侧重，我把它们的核心用途列成一张表，方便你快速对照选择：
| 工具 | 数据来源 | 主要看点 | 适合场景 |
|---|---|---|---|
| top | /proc文件系统 | 进程CPU/内存占用、负载 | 第一时间快速检查 |
| vmstat | /proc/vmstat, /proc/stat等 | 上下文切换、运行队列、IO等待 | 定位是CPU还是IO瓶颈 |
| sar | 系统日志/实时采集 | 历史趋势、分时数据 | 分析故障前后状态，做压测基线 |
| perf | PMU（性能监控单元） | 热点函数、缓存失效、分支预测 | 深入分析代码级性能 |
2.6 我的诊断流程——“三步走”
你可能已经发现了，我很少只靠一个工具就下结论。每次遇到性能问题，我基本是这么干的：
- 第一步：用top看全局。CPU、内存、负载有没有异常？哪个进程在吃资源？
- 第二步：用vmstat细分定位。到底是CPU满载（高us/sy）、还是IO等待（高wa）、还是内存压力大（高si/so）？
- 第三步：用perf/sar深入取证。如果是CPU问题，perf抓热点函数；如果是历史问题，sar看时间线。
这套流程看起来简单，但我在项目中用它解决过不下20次线上故障。举个例子：有一次业务方反馈“每天下午3点准时卡顿”。我按流程先top发现CPU没满，再vmstat看到wa飙升，最后sar -d发现那块数据盘的await从10ms涨到了200ms。再一查，原来是备份脚本每天下午3点全量扫描磁盘。把备份时间挪到凌晨，问题就消失了。
2.7 知识体系图示
下面这张图概括了这几个工具在整个性能分析链中的位置和作用范围。你可以把它当作一个快速指引：
看了这张图你可以发现，整个思路是由粗到细、由全局到局部。不要一上来就perf抓数据，那样容易迷失在细节里。先top、再vmstat、最后perf/sar，这套路我用了十年都没翻过车。
2.8 避坑指南
- 我记得有一次：用sar看CPU历史时没注意采样间隔，默认是10分钟一次的，结果峰值正好被漏掉了。后来我改成1分钟间隔：
sar -u 60 100，数据就精准多了。 - 还有一个坑：perf采样默认用
perf_event_open系统调用，在有些容器环境中会被seccomp过滤掉。如果你遇到perf_event_open failed，试试加--per-thread参数，或者检查容器的seccomp规则。 - 曾经有同行问我：“为什么我的vmstat里si/so一直是0，但内存看着不够用？”嗯，这通常是swappiness设得太低或者swap分区太小，系统选择直接OOM kill也不换出。要验证的话，
sar -S看swap利用率就知道了。
老实说，这几个工具每个人都会用，但真正用好它们的关键是养成“连续观察、交叉验证”的习惯。单一时间点的top截图往往没有说服力，而“top + vmstat + sar + perf”的组合拳才能把问题查个底朝天。