1. 性能分析基础：什么是性能分析、为什么需要 perf、性能分析的核心指标
1.1 什么是性能分析
性能分析（Performance Analysis）是一套系统性的观测、度量与诊断方法，旨在回答一个核心问题：系统当前的工作状态是否达到了预期效率？ 如果未达到，瓶颈在哪里？
在 Linux 环境中，性能分析覆盖从硬件微架构到应用层逻辑的全栈视角。它不仅仅是“看 CPU 是否跑满”，而是通过量化指标定位资源争抢、锁冲突、缓存失效、I/O 等待等深层次问题。
核心原则： 先度量，后优化。没有数据的优化是盲目的，没有优化的度量是无效的。
1.2 为什么需要 perf
Linux 系统自带多种性能观测工具（如 top、vmstat、iostat、sar），但它们存在三个共同局限：
- 采样粒度粗： 多数工具以秒级间隔输出聚合数据，无法捕捉微秒级的瞬时抖动。
- 缺乏上下文关联： 能告诉你 CPU 忙，但说不清是哪一行代码导致的。
- 硬件事件盲区： 无法直接读取 CPU 缓存未命中、分支预测失败、TLB 缺失等微架构事件。
perf 是 Linux 内核官方提供的性能剖析工具集，直接利用内核的 perf_event 子系统与 CPU 性能监控单元（PMU），克服了上述局限。它能够：
| 能力 | 说明 | 传统工具能否做到 |
|---|---|---|
| 硬件事件采样 | 读取 CPU 周期、缓存未命中、分支预测等 PMU 计数器 | ❌ 不能 |
| 软件事件跟踪 | 捕获系统调用、上下文切换、缺页中断等内核事件 | 部分（strace 但开销大） |
| 调用链分析 | 记录函数调用栈，定位热点路径 | ❌ 不能 |
| 低开销采样 | 支持基于事件的周期性采样，对生产环境影响极小 | ❌ 不能 |
| 时间关联分析 | 将多个事件按时间戳对齐，分析因果链 | ❌ 不能 |
一句话总结： 当你想知道“CPU 到底在忙什么”而不是“CPU 忙不忙”时，就需要 perf。
1.3 性能分析的核心指标
性能分析围绕四大资源维度展开：CPU、内存、I/O、网络。每个维度都有对应的关键指标和典型瓶颈模式。
1.3.1 CPU 指标
| 指标 | 含义 | 典型问题 |
|---|---|---|
| %user / %system | 用户态 / 内核态 CPU 占用率 | %system 过高可能意味着系统调用频繁或驱动问题 |
| 上下文切换（cs/sec） | 每秒 CPU 切换进程/线程的次数 | 过高（>10万/s）暗示锁争用或线程过多 |
| CPU 迁移（migrate） | 进程被调度到另一个 CPU 核心的次数 | 频繁迁移破坏缓存局部性 |
| 缓存未命中（LLC misses） | 最后一级缓存未命中率 | 高未命中率导致内存延迟成为瓶颈 |
| IPC（每周期指令数） | 每个 CPU 周期执行的指令数 | IPC < 0.5 通常意味着流水线停顿严重 |
1.3.2 内存指标
| 指标 | 含义 | 典型问题 |
|---|---|---|
| 内存使用率（%mem） | 已用物理内存占比 | 接近 100% 可能触发 OOM Killer |
| Swap 使用量 | 被换出到磁盘的内存页大小 | Swap 持续增长说明物理内存不足 |
| 缺页中断（page fault） | 进程访问未映射内存页的次数 | 大量缺页中断意味着内存访问模式差 |
| TLB 未命中 | 页表缓存未命中率 | 高 TLB 未命中会显著增加内存访问延迟 |
| 内存带宽（MB/s） | 内存控制器吞吐量 | 带宽饱和时所有内存操作都会排队等待 |
常见误区： 只看“内存使用率”是不够的。很多性能问题源于内存访问延迟而非容量不足。perf 的
perf mem 子命令可以直接采样内存访问延迟和负载/存储指令分布。
1.3.3 I/O 指标
| 指标 | 含义 | 典型问题 |
|---|---|---|
| IOPS（读写次数/秒） | 每秒 I/O 操作数 | IOPS 达到设备上限时出现排队 |
| 吞吐量（MB/s） | 每秒传输的数据量 | 吞吐量饱和导致延迟飙升 |
| I/O 等待时间（await） | I/O 请求从发出到完成的平均时间 | await > 10ms 通常意味着磁盘性能不足 |
| 队列深度（avgqu-sz） | 等待处理的 I/O 请求数 | 队列深度持续 > 2× 设备并发能力时性能急剧下降 |
| %iowait | CPU 等待 I/O 完成的时间占比 | %iowait 高说明 CPU 被 I/O 拖累 |
1.3.4 网络指标
| 指标 | 含义 | 典型问题 |
|---|---|---|
| 带宽利用率（bps） | 网络接口的收发速率 | 接近接口上限时出现丢包 |
| PPS（包/秒） | 每秒处理的数据包数量 | PPS 过高会耗尽 CPU 中断处理能力 |
| TCP 重传率 | 重传数据包占总发送包的比例 | 重传率 > 1% 通常意味着网络拥塞或对端处理慢 |
| 连接队列溢出（listen_overflows） | TCP 全连接队列满导致的连接拒绝 | 应用层 accept 速度跟不上连接建立速度 |
| 延迟（RTT） | 数据包往返时间 | RTT 抖动大影响交互式应用体验 |
1.4 性能分析的通用方法论
在实际工作中，推荐遵循 USE 方法论（Utilization、Saturation、Errors）来快速定位瓶颈：
- 利用率（Utilization）： 资源有多忙？例如 CPU 使用率 90%、磁盘吞吐量接近上限。
- 饱和度（Saturation）： 资源是否有排队等待？例如 CPU 运行队列长度、磁盘队列深度。
- 错误（Errors）： 是否有异常事件？例如网卡丢包、磁盘 I/O 错误、内存 OOM。
实战建议： 遇到性能问题，先用
top、vmstat 1、iostat -x 1、sar -n DEV 1 做快速扫描，确定瓶颈维度后，再使用 perf 进行深度采样分析。
1.5 本章小结
- 性能分析是系统性的度量与诊断过程，覆盖应用层到硬件层。
- perf 是 Linux 内核官方工具，能采集硬件事件、软件事件和调用链，弥补传统工具的不足。
- 核心指标分为 CPU、内存、I/O、网络四大维度，每个维度都有对应的关键量化指标。
- USE 方法论（利用率、饱和度、错误）是快速定位瓶颈的有效框架。