很多人跑perf stat第一眼看的往往就是cache-misses这个计数器。数字一高就觉得缓存没用明白可问起这个数到底是怎么来的、高在哪里、改哪个函数能降下来又说不清楚。这篇我不会去复述 perf 的手册页而是以一次真实做过的 cache 优化过程为线索把 perf 从统计计数、采样热点、定位到源码行的完整链路走一遍。你可以把它当成一份操作笔记也可以直接抄里面的命令和思路去排查自己的程序。这个内容适合两类人一是已经会用gcc -O2编译程序、但还没系统用过 perf 的性能分析初学者二是写过一些性能代码、知道 cache miss 是瓶颈却不知道怎么定位到具体代码行的开发者。读完你应该能回答三个问题Cache 优化到底在优化什么、perf 哪几个命令能告诉你 miss 在哪、以及改完代码后怎么验证是真的变快了。1. 为什么优化Cache利用率是性能调优的关键先别急着敲命令我和很多开发者的经验一致如果对 Cache 的工作原理没有基本概念perf 输出的那一串计数器只会让你更迷茫。你要优化一个东西前提是知道它为什么慢。1.1 Cache失效的代价远比你想的更贵现代 CPU 的算力早就不是瓶颈了瓶颈往往在数据搬运上。CPU 访问 L1 Cache 大概 1 纳秒访问 L2 大概 3-5 纳秒访问主内存则是 100 纳秒上下。这中间差了两个数量级换算成 CPU 周期更直观L1 命中大约 4 个周期L2 命中大约 12 到 15 个周期最后一级 CacheLLC命中 40 个周期左右而真正落到内存是一次 200 到 300 周期的访问。也就是说一次 cache miss 可能需要等上几百个周期期间 CPU 流水线只能停在那里。我在实际项目里经常遇到一个现象某个核心函数明明 CPU 占用率很高但你用perf stat看instructions和cycles的比例会发现 IPC 只有 0.5 左右。说明 CPU 有一大半时间在等数据而不是在执行指令。这种情况再去抠指令数没有意义真正要解决的是把数据放到离 CPU 更近的地方也就是提高 cache 利用率。所以 Cache 优化不是锦上添花而是很多服务延迟和吞吐问题的根因。比如同样一个 hash 查找逻辑如果 key 分散在内存各处每次访问都是 miss性能可能差 3 到 5 倍。这个差距远比你在代码里省几条指令来得大。1.2 Cache Miss怎么分类perf里对应什么事件理解 miss 的类型对后续用 perf 定位问题非常有帮助。通常我们按产生原因把 cache miss 分三类强制失效compulsory miss数据第一次被访问时缓存里必然没有这种 miss 没法完全消除只能靠预取提前把数据拉进 cache。容量失效capacity miss工作集超过了 cache 容量前面的数据被挤出去了后面再次访问时又要从内存拿。这对应的是程序的内存占用相对于 cache 太大。冲突失效conflict miss数据在 cache 中映射到了同一个组里明明 cache 还有空位但因为映射关系互相挤占。这种情况在路数associativity较少的 cache 上更容易出现。对应到 perf 的事件上cache-misses和cache-references是通用硬件事件很多架构上cache-misses统计的其实就是最后一级 Cache 的 miss。如果你用的是 Intel 平台还可以进一步拆LLC-load-misses、LLC-store-misses、LLC-loads、LLC-stores。这一步非常关键因为我见过不少人拿cache-misses数值去推 L1 命中率完全牛头不对马嘴。perf 里 L1 的 miss 事件通常叫l1d-load-misses和cache-misses含义不同。实操中我一般先看整体cache-misses / cache-references得到 miss 率再细化到LLC-load-misses / LLC-loads看最后一级的命中情况。如果 LLC miss 率很高基本可以断定瓶颈在内存访问。如果 LLC miss 率不高但总时间很长那问题可能在锁竞争、分支预测或其他地方别死磕 cache。2. 用perf定位Cache性能问题的具体方法perf 是个工具集不是单一命令。针对 cache 优化最常用的三个命令是perf stat、perf recordperf report、perf annotate。我带过不少同事发现最容易犯的错是上来就perf record -g抓栈抓完发现热点函数全是编译器生成的 memset 或 memcpy完全看不出问题。正确的做法应该是先 stat 后 record先看计数器再采样。2.1 先用perf stat建立基线看什么指标怎么算命中率我把建立基线这步看得很重。没有基线后面任何优化都无法量化。先跑一遍perf stat -e task-clock,cycles,instructions,cache-references,cache-misses ./your_program如果是在支持具体事件细分的平台可以再补一条perf stat -e LLC-loads,LLC-load-misses,LLC-stores,LLC-store-misses ./your_program输出里你会看到类似这样的内容1,234,567,890 cycles 2,345,678,901 instructions 456,789,012 cache-references 67,890,123 cache-misses那么IPC每周期指令数 instructions / cycles一般大于 1.0 算健康低于 0.7 就说明大概率在等内存或锁。通用 cache miss 率 cache-misses / cache-references这个数值是最后一级 cache 视角。LLC miss 率 LLC-load-misses / LLC-loads这个更能反映真实内存访问压力。建立基线的时候建议关闭 CPU 频率 scaling 带来的干扰。我用得比较多的做法是taskset绑核配合 cpupower 把核固定在最高频。否则同一份代码前一分钟跑在 1.5GHz后一分钟睿频到 4GHztask-clock和cycles都会失真。另外一个要点是要跑足够的次数。我自己的标准是至少 5 次取中位数而不是平均值。perf 的硬件计数器本身精度很高但系统的调度噪声、其他进程的中断都会干扰单次测量。取中位数可以剔除异常跳动。2.2 用perf record和annotate找到哪一行代码在制造missperf stat告诉你是高是低perf record则告诉你是哪个函数、哪一行。这里很多人会直接采样cycles或instructions我更推荐针对事件采样perf record -g -F 999 -e cache-misses ./your_program perf report -n --stdio-F 999是采样频率单位 Hz。-g是记录调用栈。设 999 而不是 1000是因为有些内核版本对整数采样频率有锁相位问题1999、999 这类奇数频率能有效避免周期性采样和程序相位的巧合让热点分布更真实。perf report出来后先看Samples列让 cache-misses 占比最高的函数排在最前面。这个函数就是你要开刀的地方。下一步用perf annotate定位到具体源码行perf annotate --stdio --symbol你的热点函数名它会同时显示汇编和对应的源码行并且用百分比标出每一行指令的 cache miss 占比。我自己看 annotate 输出有个经验重点看访存指令也就是mov、load这一类操作数在内存里的指令。如果某个mov指令的 miss 比例异常高说明它频繁访问的内存区域不在 cache 里上下文中的地址往往是某个数组或结构体字段。这一步不需要你在脑子里跑模拟器perf 已经帮你把证据链补全了。真正难的是解读miss 高的指令到底在访问什么数据结构、为什么总是 miss。这就进入下一步也是最核心的代码分析环节。2.3 常用perf模块与适用场景除了stat、record、annotate三板斧还有两个值得在 cache 优化中使用的扩展perf mem和perf c2c。perf mem record能够记录内存访问的延迟分布再通过perf mem report查看哪些内存访问延迟最高。它在定位 NUMA 访问远端内存、TLB miss、页表开销等问题时很有用。cache 优化做到后期经常会碰到这些交叉问题。perf c2c是专门分析 cacheline 伪共享的工具。如果你发现cache-misses集中在被多个线程修改的共享变量上可以用它看是哪些不同的 CPU 在打架。多线程程序的 cache 优化c2c 基本是首选工具。需要注意这两个模块在部分虚拟化环境或老内核上不可用。碰到提示not supported的时候不要死磕改用perf stat -e细分事件逐个排查。工具永远是辅助理解数据到代码的映射才是核心能力。3. 一个完整的Cache优化实例某日志处理程序从FP到优化落地为了不牵扯具体业务我用「某日志处理程序」这个虚构项目来说明完整流程。背景是一个后端服务里的解析模块每天处理大量结构化日志每个日志条目有几十个字段。优化前单条日志的平均处理时间大约是 8 微妙。压测时发现服务整体吞吐上不去CPU 占用居高不下但负载就是不高不低卡在 70% 左右。3.1 项目背景与基线数据核心数据结构是一个结构体数组里面有时间戳、级别、来源 ID、一段最长 64 字节的消息文本、若干业务字段。为了表示清楚代码大致长这样struct log_entry { uint64_t ts; uint32_t level; uint32_t src_id; char message[64]; double metric; // 其他业务字段若干 }; struct log_entry entries[MAX_ENTRIES];程序的主流程是遍历这条数组对metric字段求和按src_id统计数量还要按level过滤。听起来就是一个简单的扫描但实测数据很不理想。基线数据用perf stat跑出来是这样的指标数值任务运行时间约 2.1 秒CPU cycles约 51 亿指令数约 28 亿IPC0.55cache-references约 3.5 亿cache-misses约 1.02 亿cache miss 率约 29%LLC-load-misses约 9000 万这个 miss 率对顺序扫描程序来说太高了。理论上顺序访问内存cache 命中率应该很高才对。于是我用perf record -e cache-misses采样perf report显示热点集中在遍历结构体的循环里perf annotate进一步把问题定位到访问metric和src_id的那几条访存指令上。接下来要思考的是为什么顺序访问结构体数组还会大量 miss原因在于结构体数组的布局。log_entry里包含一个 64 字节的message加上其他字段单个条目打包下来轻松超过 128 字节。每次循环访问metric时虽然访问下一个条目的metric地址只往后挪了一个结构体的距离但中间夹着大量用不到的数据。一个 64 字节的 cacheline 里能装下的有用字段没几个大部分空间都被白占。更麻烦的是message内容通常很大把后续条目的数据从 cache 里挤出去。最终的结果就是你读的字段很稀疏cache 利用率极低。3.2 第一次优化结构体数组改成并行数组想通之后解决方向就清晰了把log_entry改成结构数组SoAStructure of Arrays。按字段拆分成多个连续数组遍历哪个字段哪个字段的数据就是紧挨着的double *metrics; uint32_t *src_ids; uint64_t *timestamps; char (*messages)[64];改成这样之后遍历metrics数组时每次 cacheline 拉进来的 64 字节里几乎全部都是下一个要用的metric数据。连续内存访问的 cache 利用率理论上可以接近 100%。代码改动不大前后台接口都不用动只是把内部的存储布局换了。重新编译再跑同样的压测指标优化前优化后运行时间2.1 秒1.4 秒cache miss 率29%11%IPC0.550.91这一趟改动唯一的成本是把存储布局重构成 SoA收益是 33% 的耗时下降。没有任何算法层面的花活就是数据局部性的胜利。这也是为什么我一直强调cache 优化首先是数据结构优化不是指令优化。3.3 第二次优化二维数组遍历顺序的调整同一份程序里还有另一个典型问题一个二维数组的统计逻辑。原始代码写了双重循环但顺序是i在外、j在内j表示列方向。问题在于 C 语言的多维数组按行优先存储内层循环遍历列意味着每个元素的地址跨了整行的距离访问间隔远大于 cacheline。for (int i 0; i ROWS; i) for (int j 0; j COLS; j) sum matrix[i][j];改成内层循环遍历行for (int j 0; j COLS; j) for (int i 0; i ROWS; i) sum matrix[i][j];看起来只是交换循环顺序但对 cache 来说是质的改变。按行遍历时相邻元素在内存中相邻CPU 拉进 cacheline 的数据马上能用。按列遍历时每读一个元素都要跳到很远的地址每次基本都是一次 miss。两种写法的运行时间差距在数组变大后可以达到 5 倍以上。修改后二次跑 perf数据如下指标SoA 之后循环交换之后运行时间1.4 秒1.1 秒cache miss 率11%7%到这里原先的 2.1 秒变成了 1.1 秒程序吞吐压测刚好过了阈值。这个案例能说明问题perf 不只是给你波形图看热闹的它能清楚告诉你 miss 出现在哪而分析之后发现大部分问题的本质都是数据布局和访问顺序不匹配硬件特性。3.4 第三次优化prefetch指令什么时候值得用做完前两步我还想尝试预取。代码里有一段分支密集的逻辑根据不同的level走不同处理路径提前判断之后必然要访问某个数组的特定下标。这个下标从业务逻辑上能提前知道于是可以用__builtin_prefetch手动把数据拉进 cache__builtin_prefetch(table[next_index].key, 0, 3);第三个参数是局部性等级取值 0 到 33 代表希望数据留在所有层级的 cache 中。这里要说实话手动 prefetch 的效果远没有大多数人想象中那么明显尤其在现代 CPU 的硬件预取器已经很强的情况下。在这个项目里手动加 prefetch 后运行时间从 1.1 秒变成 1.08 秒基本在噪声范围内。我的经验是能靠改数据结构布局解决的不要优先上 prefetch。硬件预取器对规则访问模式的识别已经相当好手动 prefetch 只有在访存模式不规则、且你能提前足够周期知道地址时才有效。如果 prefetch 距离太近数据还没拉进来就要用照样 miss距离太远又可能把有用的 cacheline 挤出去得不偿失。对多核缓存一致性的干扰也要考虑进去。4. 常见问题与排查技巧实录perf 用多了自然会碰到各种坑。这里整理几个我实际踩过的给第一次用的人排排雷。4.1 采样不到热点/权限问题刚接触 perf 的人大概率会遇到三件事提示permission denied、采样出来全是unknown、或者事件计数全是 0。权限问题通常是/proc/sys/kernel/perf_event_paranoid设置限制导致的。临时查看一下cat /proc/sys/kernel/perf_event_paranoid如果值为 3 或更高普通用户基本什么都干不了。调试机上可以临时调低注意这只是开发环境做法生产环境不要乱动权限配置。另一种方式是以足够的权限运行 perf但你要提前确认所在环境是否允许这样做。采样全是 unknown 或者函数名解析不出来多数是因为程序被 strip 了符号或者 perf 没找到 debug 符号。编译时用-g不要用-s等去符号选项。对动态库可以先跑perf buildid-list看看能否拿到 build-id再用perf archive归档符号。事件计数为 0 还有一种可能是写错了事件名。perf 的 PMU 事件名依赖具体 CPU 架构比如cache-misses在大多数 x86 上能用但如果是 ARM 平台能用的事件名可能不同。先跑perf list看当前支持的硬件事件列表再挑事件。4.2 短程序测不准循环次数与采样频率如果一个程序整体运行时间只有几十毫秒perf stat测出来的数据往往波动很大。不要在这么短的时间窗口里纠结单个指标我对短程序的做法是把核心操作放大到至少 1 到 2 秒的运行时长。具体手段是在测试程序里加足够多的重复次数或者固定在一个数据规模上反复跑多轮。采样频率也要匹配程序的运行时长。-F 999的意思是每秒采 999 个样本跑 1 秒大概采到 1000 个样本。样本太少的话perf report的统计结果不稳定。如果你看到热点函数的样本数量只有几十个数据基本不可信要么加长运行时间要么提高采样频率但频率过高会增加性能开销反过来影响测量。我自己的标准是热点函数的 sample 数量不低于 500 个整体样本在 2000 以上才敢下结论。4.3 编译优化、超线程与绑定策略带来的假象编译器优化级别会影响 cache miss 的分布。-O0编译的代码经常因为栈上局部变量的反复存取制造假性 miss-O2之后这些访问会被优化进寄存器miss 分布才接近真实热点。所以性能分析请用和线上发布一致的编译选项不要去分析一个从未上线的调试版本。超线程对 cache 测量的影响也很隐蔽。同一个物理核上的两个逻辑核共享 L1 和 L2如果系统调度把你的程序在两个逻辑核之间来回迁移你看到的 cache-misses 会被人为放大。用taskset -c 0之类的把程序固定在一个核上可以减少这种调度噪声。固定核之后还要确认 CPU 频率没有被省电策略压低否则 IPC 和周期数据同样失真。另外容器或虚拟机里跑 perf 需要额外小心。很多虚拟化平台无法完全暴露 PMU 计数器perf 只能看到虚拟化层模拟的事件数据参考价值有限。真碰上这种情况可以考虑在宿主机上做基准或者在容器内用软件事件比如cpu-clock做相对对比。5. 把perf固化进日常优化工作流单次 perf 分析只能算一次体检真正让团队受益的是让 perf 的测量成为日常开发的一部分。5.1 一个可复用的perf对比脚本我习惯在项目里维护一个简单的脚本输入是程序路径和绑核参数输出是一个时间戳标记的 perf stat 结果文件。脚本本身不复杂思路是每次改动前后都自动留底方便回溯。#!/bin/bash set -e PROG$1 PERF_DATAperf_$(date %Y%m%d_%H%M%S) taskset -c 2 perf stat -x, -e task-clock,cycles,instructions,cache-references,cache-misses,LLC-loads,LLC-load-misses \ -o ${PERF_DATA}.stat $PROG perf record -g -F 999 -e cache-misses -o ${PERF_DATA}.perfdata -- $PROG-x,让输出变成 CSV 格式后续可以用脚本批量对比。每次改动前后把perf_*.stat放到同一个目录跑一个简单的 diff 就能看到 cache miss 率、IPC 的变化趋势。别再靠记忆里的好像快了一点所有优化都从这份数据里找证据。5.2 数据如何纳入版本管理在代码仓库里我不会直接存放 perf 原始数据因为二进制文件体积大且没法有效 diff。我推荐把关键指标沉淀为文本摘要也就是每次优化后把perf stat的 CSV 结果、perf report的热点函数 top 10、运行时间压测结果一起放进一个benchmarks/目录以日期和 commit 号命名。有了历史基线后续任何一次重构只要跑一遍同样的脚本马上能判断有没有引入 cache 回退。我踩过这样的坑某次重构后功能测试全过但一周后才发现关键路径变慢了 15%因为当时没有在 merge 前重跑 perf 基线。现在我们把 perf 对比作为合入前的检查项之一推送代码时如果 cache miss 率明显上升CI 会直接拦截并提醒人工确认。这个流程的成本很低但避免了大量上线后发现变慢再回滚的尴尬局面。最后再分享一个个人习惯改完代码后不要只盯着cache-misses的绝对数值。先跑一次perf stat确认 miss 率确实降了再跑完整 benchmark 看总耗时。如果 miss 率降了但耗时没变说明瓶颈可能不在 cache而在别的地方比如内存带宽、锁、或者是系统调用。如果 miss 率没降但耗时涨了那更要警惕可能只是改动把 cache 压力转移到了别处。perf 最大的价值是让你把感觉程序慢变成可验证的数据判断。优化 cache 利用率这件事前期看起来像是内存布局的书本知识但真正操作一遍会发现它就是在排查数据访问和硬件特性之间的错位。先找到错位的地方再调整数据组织方式性能提升往往比你想的顺利得多。