Linux perf stat 怎样先看 CPU 指标

排查 Linux 程序变慢时，第一轮不要一上来就用复杂采样。perf stat 更适合先回答一个窄问题：这段命令消耗了多少 CPU 周期，完成了多少条指令，分支和缓存是否出现异常。通常先看 cycles、instructions、branches、branch-misses，再按现象补充缓存事件。下面的命令和图示是静态说明，不代表在当前机器上实际执行过的输出。

先用默认计数建立 CPU 基线

对一个可重复的命令，先保留输入、环境和参数，只包一层 perf stat。示例中的 ./worker --input sample.dat 只是待测程序占位符。

# 先看默认软件事件和硬件事件，建立同一场景的基线
perf stat -- ./worker --input sample.dat

# 只保留最常用的 CPU 指标，便于多次结果对照
perf stat -e task-clock,cycles,instructions,branches,branch-misses -- ./worker --input sample.dat

重点不是某个绝对数字，而是同一输入下的相对变化。cycles 上升而指令数近似不变，可能意味着等待、频率或微架构效率变化；指令数和 cycles 同时上升，则可能是工作量本身变大。由 instructions / cycles 得到的 IPC 只适合做方向判断，不能跨不同 CPU 直接比较。

按问题选择缓存和分支指标

当程序的指令数没有明显增加，却出现执行时间变长，可以把缓存和分支指标放进同一次测量：

# 用事件名显式选择指标；具体可用名称以本机 perf list 为准
perf stat -e cycles,instructions,cache-references,cache-misses,branch-misses -- ./worker --input sample.dat

# 先预热，再重复测量，减少首次加载和调度噪声
perf stat -r 5 -e cycles,instructions,cache-misses -- ./worker --input sample.dat

cache-misses / cache-references 可以作为同一平台上的粗略未命中比例，但它不是“慢的证明”：顺序扫描大数据也可能有较高计数，命中率下降还可能来自工作集变大。分支未命中率升高时，再去看输入分布、分支规律和热路径，别直接把所有问题归为 CPU 缓存。

用事件可用性校准 perf stat 结果

perf list 展示当前内核和 PMU 可识别的事件。不同架构的缓存事件名字、含义和精度并不完全一致，所以不要把某台 Intel 机器上的事件名原样搬到 ARM 或混合架构。

# 查看本机可用事件和 metric 名称
perf list

# 用较少事件避免硬件计数器不够时发生过多复用
perf stat -e '{cycles,instructions}' -- ./worker --input sample.dat

如果输出出现 ，说明事件在当前环境不能测； 则常见于事件没有获得有效计数时间。一次塞入太多事件时，perf 可能进行 multiplexing，结果会带缩放或运行比例。做指标对比时，宁可拆成两组稳定测量，也不要把不同时刻采到的事件强行算成精确比值。

重复测量后再决定下一步

一轮结果只够定位方向。先固定输入和 CPU 亲和性，确保待测进程有足够长的执行区间；短到几十毫秒的命令容易被启动、页面缺页和调度放大。对于持续运行服务，可以使用目标 PID 或较长的窗口，但要把采集窗口内的请求量记录下来，否则指标没有可比的分母。

如果 IPC 下降但缓存和分支都稳定，下一步应检查锁等待、系统调用或 I/O；如果缓存未命中和执行时间随数据规模同步增长，再看访问模式和数据布局。perf stat 的价值是把“感觉变慢”变成可复测的对照，不是替代火焰图、源码分析或业务指标。

常见问题

perf stat 默认测的是哪个对象

命令后跟可执行程序时测该命令及其子进程；不指定目标时才可能进入系统范围模式。脚本中应显式写出待测命令和参数。

cache-misses 越高就一定越慢吗

不一定。还要看缓存引用总量、内存访问延迟、工作集和程序实际耗时；高计数可能只是处理了更多数据。

为什么同一命令每次 IPC 不一样

常见原因包括输入变化、预热状态、CPU 频率、调度迁移、共享缓存竞争和计数器复用。用 -r 重复测量并记录场景后再比较。

先用少量稳定事件建立基线，再按异常选择缓存或分支指标，最后结合可用性和重复测量解释结果，这样更容易把 perf stat 的数字连接到真实优化动作。