2. 性能分析工具链概览：perf、eBPF、ftrace、strace、top/htop、vmstat、iostat、sar等工具介绍
说实话，刚入行那会儿，我面对一堆性能工具是懵的。perf、eBPF、ftrace、strace……每个都号称能定位问题，但到底该用哪个？
后来踩的坑多了，我慢慢总结出一套自己的「工具选择心法」。今天就跟大家聊聊这个工具链，帮你理清思路。
2.1 工具分类：先看问题，再选工具
性能分析，说白了就是回答三个问题：
- 资源够不够？ —— CPU、内存、磁盘、网络
- 谁在吃资源？ —— 哪个进程、哪个线程、哪段代码
- 为什么慢？ —— 锁竞争？IO等待？调度延迟？
不同的工具，擅长回答不同的问题。我习惯把它们分成三层：
第一层：系统级概览 —— top/htop、vmstat、iostat、sar
第二层：进程级追踪 —— strace、perf
第三层：内核级深挖 —— ftrace、eBPF
你想想看，如果CPU飙到100%，你第一反应是什么？我肯定先敲top，看看是哪个进程在搞鬼。这就是第一层工具的价值——快速定位「谁」。
2.2 系统级工具：先看全局
top / htop
这两个是入门必备。我个人更偏爱htop，因为它有颜色，能直观看到CPU核心的负载分布。不过在生产环境，很多机器没装htop，所以top还是基本功。
我记得有一次，线上服务响应变慢，我top一看，CPU idle 99%，但wa（IO等待）高达30%。嗯，问题不在CPU，在磁盘。这就是top的价值——给你一个方向。
小技巧： top里按1可以看每个CPU核心的负载，按P按CPU排序，按M按内存排序。这些快捷键我闭着眼都能按出来。
vmstat
vmstat 是我排查内存和CPU问题的老朋友。它输出简洁，一行就能看出系统整体健康度。
# 每1秒输出一次，共5次
$ 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 123456 1234 567890 0 0 10 20 100 200 30 10 60 0 0重点关注r（运行队列）和b（阻塞进程）。如果r持续大于CPU核心数，说明CPU不够用了。如果b很大，那多半是IO在拖后腿。
iostat
磁盘性能就看它。我曾经遇到一个数据库写入慢的问题，用iostat -x 1一看，await（平均IO等待时间）飙到200ms，%util接近100%。
说白了，磁盘已经忙不过来了。后来换成SSD，问题解决。嗯，有时候硬件升级比代码优化更直接。
sar
sar 是历史数据的记录者。它能帮你回答「昨天下午3点发生了什么？」。我习惯在排查偶发问题时用它，比如「为什么每天凌晨2点CPU会飙一下？」
# 查看当天CPU使用情况
$ sar -u
# 查看内存使用
$ sar -r
# 查看网络流量
$ sar -n DEV注意： sar 需要提前开启数据采集（sysstat服务）。很多新装系统默认没开，等你需要查历史数据时才发现没有记录。我曾经吃过这个亏，后来每装一台机器第一件事就是开sar。
2.3 进程级追踪：深入细节
strace
strace 跟踪系统调用。说白了，就是看进程跟内核说了什么悄悄话。
有一次，一个程序启动特别慢。我用strace -c统计系统调用耗时，发现read()调用占了90%的时间。再一看，程序在逐字节读取配置文件……改成批量读取后，启动时间从30秒降到2秒。
# 跟踪指定进程的系统调用
$ strace -p 12345
# 统计系统调用耗时
$ strace -c -p 12345避坑指南： 千万不要在生产环境长时间跑strace，它会大幅拖慢目标进程。我一般只跑几秒钟，或者用-e过滤特定系统调用。
perf
perf 是性能分析的瑞士军刀。它能做CPU采样、硬件事件计数、跟踪点分析……功能强大到让人又爱又恨。
我个人最常用的是perf top和perf record/report。
# 实时查看CPU热点函数
$ perf top
# 采样30秒，生成报告
$ perf record -a -g -- sleep 30
$ perf report记得有一次，一个服务CPU使用率忽高忽低。用perf top一看，热点函数是spin_lock。嗯，锁竞争。再配合perf record -g看调用链，很快就找到了是哪个锁在打架。
2.4 内核级深挖：终极武器
ftrace
ftrace 是内核自带的跟踪器，零依赖。它能看到函数调用、调度事件、中断等内核内部行为。
我一般用它来排查调度延迟问题。比如「为什么这个线程睡了10ms才被唤醒？」
# 开启函数跟踪
$ echo function > /sys/kernel/debug/tracing/current_tracer
# 跟踪特定函数
$ echo schedule > /sys/kernel/debug/tracing/set_ftrace_filter
$ cat /sys/kernel/debug/tracing/trace个人经验： ftrace 的接口是文件系统，用起来有点原始。我习惯写个脚本封装一下，不然每次敲一堆echo太累了。
eBPF
eBPF 是近几年最火的内核技术。它允许你在内核中安全地运行沙箱程序，动态采集数据。说白了，就是给内核装了个「可编程探针」。
我用eBPF做过不少有意思的事：
- 实时统计每个TCP连接的延迟分布
- 追踪文件读写，精确到哪个进程、哪个文件、耗时多少
- 监控内存分配热点，找出谁在频繁malloc/free
# 用bpftrace统计系统调用次数（eBPF的前端工具）
$ bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }'注意： eBPF 需要较新的内核版本（4.8+），且需要开启CONFIG_BPF。老系统上就别想了，老老实实用ftrace或perf。
2.5 工具选择：我的决策流程
说了这么多，到底怎么选？我画了张图，帮你理清思路：
这张图是我自己的经验总结。简单来说：
- 先看系统级 —— top/vmstat/iostat/sar，快速定位是CPU、内存还是IO问题
- 再看进程级 —— strace/perf，找到具体是哪个系统调用或函数在消耗资源
- 最后内核级 —— ftrace/eBPF，深挖内核内部行为，比如调度延迟、锁竞争
大多数问题到第二层就能解决。只有那些特别诡异的问题，才需要动用eBPF这种大杀器。
2.6 总结：工具是死的，思路是活的
说了这么多工具，其实我想表达的是：工具只是手段，思路才是核心。
你不需要把所有工具都学透。我用了十年内核，perf的很多高级功能也没用过。关键是遇到问题时，知道该用什么工具、看什么指标、怎么分析。
我个人习惯是：先怀疑最可能的原因，用最轻量的工具验证。如果不对，再逐步深入。千万别一上来就上eBPF，杀鸡用牛刀。
最后分享一个心得： 性能分析不是一次性的。我每次优化完，都会把当时的分析过程、工具输出、优化方案记录下来。下次遇到类似问题，直接翻笔记，效率翻倍。
好了，工具链就聊到这儿。下一章我们深入perf，看看这个瑞士军刀到底怎么用出花来。