★ FEATURED ARTICLE 前阵子我接到某后端服务一个很磨人的问题机器是 16 核CPU 占用始终不到一半并发一上来单请求延迟却变成锯齿状。常规武器都试过了——锁竞争看了、上下文切换看了、网络和磁盘队列也看了全都没问题。最后是perf性能分析工具帮我把目光拽到了 CPU 的 cache 命中率上一抓一个准热点函数的 L1 cache miss 率高到离谱大量时间都耗在等内存返回上算法复杂度再低也跑不快。这篇文章就围绕“用 perf 优化 cache 利用率”这条主线来写。内容是一个我在某数据处理模块上完整跑过一遍的真实过程从用perf stat读基线到perf record抓热点函数再到perf annotate看到具体是哪一条访存指令在反复 miss最后做布局优化、伪共享修复重新量化前后差异。适合正在用 C/C/Rust 写服务端逻辑、或者在做图像/矩阵/搜索类算法又总觉得“代码已经很优了但就是慢”的人参考。1. cache miss 为什么值得用 perf 单独追1.1 先接受一个事实内存比 CPU 慢太多现在随便一颗桌面级 CPU主频都在 3GHz 往上一个周期大约 0.33 纳秒。而访问主内存的延迟按现代 DDR 内存的常见水平来看大概要 80 到 120 纳秒。这相当于什么概念CPU 在这 100 纳秒里能执行 300 多个普通指令但一个从内存取数的指令只能干等着。CPU 设计者为了解决这个差距放了好几级高速缓存L1 最快通常几十 KB延迟几个周期L2 几百 KB延迟十几到几十个周期L3 有几十 MB延迟几十个周期。数据如果命中 L1花费几乎可以忽略一旦 miss 到主内存就是上百纳秒的代价。所以一个程序“算得快不快”很多时候不是在比谁的指令多而是在比谁的访存局部性好。这里可以打个比方你写代码就像在食堂打饭L1 cache 是你桌面上的餐盘L2/L3 是后厨备好的半成品主内存才是外面的大仓库。每次都只拿一点点、反复跑仓库人再多也快不起来一次把一段时间要用的菜都摆到备餐区效率完全不同。1.2 真正会拖垮程序的三种 cache 差布局新手容易以为 cache miss 只跟“内存太大装不下”有关但实践中我见到的坑基本都是这三种第一种是遍历方向写反了。二维数组在内存里按行连续存储你如果按列去循环每取一个元素都要跳到很远的地址cache line 里装载的邻居数据全浪费了。这种问题在矩阵乘法、图像滤波、数据库列存转置里特别常见一行代码顺序调整性能能差好几倍。第二种是结构体太“肥”。比如一个用户记录结构体里既有频繁访问的 id、状态字段又有很少碰的长文本、备注信息。每次加载一条记录CPU 都会把包含这些字段的一整条 cache line通常是 64 字节搬进缓存。如果你只需要其中 8 个字节剩下 56 字节都是陪跑而缓存容量有限很快被挤爆下一轮访问又 miss。这就是典型的热冷数据混布。第三种是多线程伪共享。两个线程各写各的变量编译器把这两个变量放在了同一条 cache line 上。线程 A 哪怕只改一个字节为了保证多核一致性整条 cache line 都会在其他核心上失效线程 B 再改自己那个变量时又得重新同步。两边互相拖后腿表现就是“线程越多越慢”。1.3 什么时候该怀疑 cache miss不是说每次性能差都要先怀疑 cache。我的习惯是先排除掉明显的问题CPU 是否绑核、系统负载是否过高、有没有频繁的系统调用、锁竞争和线程调度是否异常。如果这些都正常再看一个信号——CPU 占用不高但程序很慢或者算法复杂度明明降下来了运行时间却没跟着降这时候就该往访存效率上想了。我在模拟项目 X 里遇到的场景就非常典型一个 4K×4K 的浮点矩阵统计模块代码看起来只有一个两重循环时间复杂度就是 O(N²)怎么算都不应该跑出几百毫秒。但实测单次矩阵求和竟然要将近一秒。把perf拉出来看cache miss 一条数据就把问题暴露了。2. perf 能干什么一条命令把热点钉在指令上2.1 perf 家族命令一览别只盯着 record/report很多人提到 perf 就条件反射式地执行perf record加perf report其实 perf 是一个工具箱针对性能问题不同阶段有不同工具。命令典型用途什么时候用perf stat跑一遍程序汇总各类硬件计数器先量化看全局指标是否异常perf record按固定频率采样生成 perf.data找到热点函数和调用路径perf report展示采样结果按开销排序已经抓完数据分析热点perf annotate对热点函数做指令级标注想看到底是哪一行汇编在耗费时间perf top实时显示当前系统热点不适合跑批任务适合查线上瞬时状态perf c2c做 cache line 级别的竞争分析怀疑伪共享或 NUMA 访问不均时使用优化 cache 利用率的标准动作基本就是perf stat定位方向perf record抓函数perf annotate钉指令。三个工具配合使用就能把问题从“程序慢”一路收敛到“这一行汇编 load 指令 miss 太多”。2.2 采样原理硬件计数器和周期性中断perf 依赖现代 CPU 自带的 PMUPerformance Monitoring Unit性能监视单元也就是一组硬件性能计数器。这些计数器能在硬件层面记录 cache miss、分支预测失败、指令周期等事件几乎不占用程序运行时间。需要明确一点perf record 不是一行行单步调试而是周期性采样。默认按照固定频率触发中断在一个中断点上记录当前正在执行的指令地址和调用栈。样本数量够多之后统计哪个函数出现频率高就认为它是 CPU 开销热点。这里有一个很实用的参数-F 99。它表示每秒采样 99 次故意不用 100 而用 99是为了避免和某些固定频率的任务比如刚好是 100Hz 的定时器产生相位共振导致采样结果周期性失真。以前我看过不少采出来的热点都是同一个空闲线程的情况多半就是采样频率跟调度周期撞上了。2.3 使用前的权限和环境准备perf 默认会受内核参数kernel.perf_event_paranoid影响。很多 Linux 发行版默认值较高普通用户执行perf record会提示Permission denied。最简单的临时办法是把 paranoid 值调低sudo sysctl -w kernel.perf_event_paranoid-1这个设置重启后会失效但用来做一次性能分析足够了。如果不想动系统参数也可以用sudo perf record只是后面生成的 perf.data 需要 root 才能读。另外要注意很多精简容器镜像里没有perf命令需要单独安装linux-tools或perf-tools-unstable之类的包版本最好和内核版本匹配。除了权限环境稳定性也很重要。分析 cache 行为时CPU 频率如果忽高忽低测出来的耗时和 miss 数据会有噪声。所以要尽量绑核运行并且临时把 CPU 调频策略锁到 performance 档这一步我放在下一节实验环境里细说。2.4 perf stat / record / annotate 的分工从使用层级上来讲perf stat是“宏观体检”。它直接读取硬件计数器把整个程序运行期间的 cycles、instructions、cache misses 总数给出来不涉及采样准确性很高。缺点是只有全局总量没有函数级信息。perf record是“热点扫描”。它不关心总量而是按事件触发采样。比如指定-e cache-misses就是每次 cache miss 时打个标记记录当前指令位置。这样采样出来的 perf.data 里集中出现的样本就是 miss 最频繁的代码位置。perf annotate是“显微镜”。在 report 里看到一个热点函数后进入 annotate 视图它会把目标函数每条汇编指令旁边的计数器值标出来访存指令前面那一列数字特别大问题基本实锤。这个视角对判断“到底是循环本身问题还是某一条特定 load 导致的”特别管用。3. 造一个合格的实验环境把问题量化3.1 模拟项目 X4K 矩阵访问程序这次优化我拿模拟项目 X 开刀它本质上是一个 4096×4096 的 double 数组处理模块。第一步先复现问题代码故意保留了两种访问路径一个按行求和一个按列求和下面还有一个结构体数组热冷字段混用的场景。因为后面要展示优化效果所以我把原始版本叫 v1优化版本叫 v2。#include stdint.h #include stdio.h #include time.h #define N 4096 static double matrix[N][N]; double sum_rows(void) { double s 0.0; for (int i 0; i N; i) { for (int j 0; j N; j) { s matrix[i][j]; } } return s; } double sum_cols(void) { double s 0.0; for (int j 0; j N; j) { for (int i 0; i N; i) { s matrix[i][j]; } } return s; } int main(void) { volatile double r 0.0; r sum_rows(); r sum_cols(); printf(%f\n, r); return 0; }这个项目的代码故意写得非常“教科书”因为真实业务里你很难一眼看到问题而矩阵访问则是 cache 局部性最具代表性的场景。按行遍历时内存地址连续递增每 64 字节的 cache line 被完整利用按列遍历时每次跳 4096 个 double约 32KB等于把前面载入的 cache line 全部浪费掉。3.2 编译与运行环境稳定化编译参数我用的是-O2 -g。有人图省事直接上-O3但优化 cache 分析时-O3可能引入自动向量化和循环展开导致热点分布和默认行为差异很大。我建议先用-O2看清原始访存模式再考虑更高等级优化。gcc -O2 -g -o demo_v1 demo_v1.c运行前做三件事把进程绑到一个固定 CPU 上锁住 CPU 频率关闭无用后台任务。绑核用taskset -c 0调频策略用cpupowersudo cpupower frequency-set -g performance taskset -c 0 ./demo_v1为什么要绑核因为进程如果在多核之间迁移cache 内容会跟着失效测出来的 miss 数据会掺入大量调度噪声。这个细节在做优化前后对比时尤其关键否则你无法区分改善是来自代码改动还是运气。3.3 第一轮 perf stat读出基线先跑一遍全局计数把所有跟 cache 和指令执行相关的指标都拉出来perf stat -e task-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,cache-references,cache-misses,L1-dcache-loads,L1-dcache-load-misses,branches,branch-misses -r 3 taskset -c 0 ./demo_v1-r 3表示重复 3 次取汇总结果能有效减少随机波动。我这套环境上得到的大致数据如下不同代处理器会有浮动但量级关系不会变事件数值说明cycles约 18.6 亿CPU 总周期数instructions约 21.3 亿CPU 执行指令数IPC约 1.15每周期指令数不够高cache-references约 3.1 亿访问缓存层次结构的次数cache-misses约 1.6 亿末级缓存未命中次数L1-dcache-load-misses约 4.1 亿L1 数据缓存访问未命中branch-misses约 512 万分支预测未命中不高time elapsed1.83 秒总耗时注意这里 cache-misses 是末级缓存L3 左右的 missL1-dcache-load-misses 是 L1 的 miss。矩阵按列访问时L1 miss 会非常高因为每次加载 double 都带走相邻 7 个没用到的 double而 4096×4096×8 字节约 128MB 的工作集又远大于 L3完全没法靠容量缓存兜底。3.4 基线怎么解读IPC 和 miss rate拿到数据后不要急着优化先算两个关键比例。第一个是IPCInstructions Per Cycle。普通乱序执行的 CPU 在良好局部性下IPC 能做到 2 到 4如果只有 1 左右说明 CPU 大量时间在等待数据。基线里 IPC 只有 1.15不是 CPU 不会算而是 load 指令阻塞了后端。第二个是miss rate。cache-misses 除以 cache-references约 51.6%。这个数字高得离谱正常优化良好的程序L3 miss 率通常控制在 10% 以下。基于这个量化结果可以下结论程序主要瓶颈是访存不是 CPU 算力。注意perf stat 给的是全局累计值它告诉你“问题很严重”但不会告诉你“哪一行代码造成的”。所以下一步必须上采样工具把热点钉到函数和指令级。4. 锁定 hotspotperf record 到 perf annotate 的完整链路4.1 用 cache-misses 事件做一轮采样基线确认问题方向后我用perf record针对 cache miss 事件做一轮采样。这里指定事件而不是用默认的 cycles是因为我们的首要矛盾是 cache miss直接用 miss 事件采样能让热点分布更贴合真实瓶颈。perf record -e cache-misses -F 99 -g taskset -c 0 ./demo_v1-g表示记录调用栈这样后面不仅能知道哪个函数 miss 多还能看到它是被谁调上来的。采样过程会给程序带来一点额外开销但 99Hz 的采样频率很低对结果影响可以忽略。跑完后当前目录会出现 perf.data 文件。如果程序要跑很久也可以配合-o perf_demo.data单独指定输出文件避免覆盖之前的数据。4.2 perf report 排序从上到下收窄执行分析perf report -n --sort comm,dso,symbol在这个界面里我看到了和预期一致的结果sum_cols占到了几乎 88% 的 cache miss 样本sum_rows只有 11% 左右。这已经说明问题基本出在列遍历上不需要再猜。如果热点分散在好几个函数里就继续按函数逐个展开。我这里列出两个指标帮助判断Samples是命中样本数Command是进程名Shared Object是二进制或动态库。如果某个动态库名字看起来陌生比如图形驱动、加密库那它本身可能不是热点来源要找调用方。4.3 perf annotate 看指令级证据函数级的结论还不能让我完全放心万一是编译器帮忙做了循环优化呢为了拿到实锤进入指令级视图perf annotate -l --symbolsum_cols-l会把汇编映射回源码行号。输出里对应内层循环的addsd浮点加法和movsd从内存加载 double指令旁边样本计数明显集中在movsd这一条。这些都是 load 指令它触发 cache miss 的比例远高于其它指令。顺带解释一下为什么movsdmiss 多按列访问矩阵时内层循环步长是 4096 个元素也就是 32KB远超一个 cache line 的覆盖范围。每次movsd都要重新从内存取数L1 和 L2 都失效最终还是到内存拿数据。CPU 流水线遇到这样的访存停顿再多的执行单元也是闲着。4.4 一个容易被误读的点调用来源 vs 自身 miss看perf report时新手常犯一个错误只盯样本最多的函数然后直接改它。其实还要区分两种情况——这个函数是“自己真的 miss 多”还是“被某个上游函数调用而上游函数传入了糟糕的访问模式”。比如我这次sum_cols是自身循环实现问题直接改循环方向就行。但很多业务系统里热点函数是memcpy、hash_lookup这类基础函数它们的 miss 来自调用方传入的大块随机数据。这时候要在 report 里按调用链展开展开号找到真正负责制造访问模式的上层函数才有优化意义。还有一个实用技巧perf report --sortcomm,dso,sym --call-graph可以看到调用栈关系。如果热点函数的调用者很多就先用-g抓栈看哪一条调用路径贡献的样本最多优先优化那条路径。别一上来就重写底层函数那往往是白费力气。5. 优化动手布局、遍历、预取、伪共享5.1 行主序遍历调整循环顺序收益最直接第一个修复没有任何魔法就是把sum_cols的内外层循环对调改成和sum_rows一致的行主序遍历。double sum_cols_fixed(void) { double s 0.0; for (int i 0; i N; i) { for (int j 0; j N; j) { s matrix[i][j]; } } return s; }这一步改完L1 miss 数量会下降一个数量级。原因很简单行主序时一次 cache line 载入能覆盖连续 8 个 double内层循环几乎全部命中。编译器自动向量化也能更好地发挥作用因为连续内存的addsd可以被打包成 SIMD 指令。5.2 热冷字段分离让结构体别再“肥”矩阵循环只是热身。模拟项目 X 里还有一块真正贴近业务的代码一长串用户记录每条记录既有一个频繁更新的last_active字段又有一个几乎不读的bio长文本。原始结构体两个字段紧紧挨在一起每次只改状态位却被迫带上冗长 bio 的 cache line 进出。v1 版本结构体大概长这样typedef struct { char name[32]; uint64_t user_id; uint64_t last_active; char bio[1024]; uint32_t status; } user_record_v1;一条记录超过 1KB遍历一万条就是 10MB 以上的工作集而且每个 64B 的 cache line 里真正热的数据只有 8 到 16 字节。优化方案是把冷热字段拆开热数据放紧凑结构体冷数据单独存typedef struct { uint64_t user_id; uint64_t last_active; uint32_t status; char name[32]; } user_hot_v2; typedef struct { char bio[1024]; } user_cold_v2;这样热结构体大小大约 48 字节能在一个 cache line 里装下遍历 hot 数组时每条记录最多 miss 一次后续连续记录又有预取帮助。冷数据虽然占空间但那是低频访问不参与热点路径。这不是什么高深技巧就是老生常谈的“结构体布局影响缓存命中”但实际代码里敢拆的人不多多数是担心改动面大。5.3 分块阻塞把工作集切成 cache 友好小块有些算法没法改变访问方向比如矩阵转置、卷积、图遍历。这时可以用分块loop tiling把计算拆成适合 cache 容量的小块让每一块数据在被替换出去之前得到足够多的重用。矩阵乘法是经典例子。传统三层循环写法内层累加时A 矩阵按行取、B 矩阵按列取两个矩阵的访问模式互相冲突。切块后每次只处理一个 64×64 的小块这个小块能塞进 L2/L3 缓存反复命中后才推进到下一个块#define TILE 64 void matmul_tiled(const double *A, const double *B, double *C, int n) { for (int i 0; i n; i TILE) { for (int j 0; j n; j TILE) { for (int k 0; k n; k TILE) { for (int ti i; ti i TILE; ti) { for (int tj j; tj j TILE; tj) { double acc 0.0; for (int tk k; tk k TILE; tk) { acc A[ti * n tk] * B[tk * n tj]; } C[ti * n tj] acc; } } } } } }分块大小的选择需要实测。块太大超出缓存容量后 miss 率反弹块太小循环边界判断开销增加。在这类模拟项目里64 到 128 是比较稳的起点然后用perf stat跑几组不同 TILE 值对比 miss 率和耗时再取最优。5.4 伪共享多线程场景下的隐藏大坑模拟项目 X 的另一个版本里我让 8 个线程各自维护一个计数器每个线程只更新自己的那份。代码逻辑完全无锁、无共享变量按道理应该线性扩展。结果线程数从 1 涨到 8性能只提升了 1.5 倍。这就是伪共享的典型症状。perf stat 里 cache-misses 数量并不低但如果只分析 miss 率可能还会往“数据结构太大”上猜。正确的做法是用perf c2c这类工具检查 cache line 级别的读写冲突或者直接看数据结构布局。我在代码里加了 64 字节对齐的隔离struct worker_counter { volatile uint64_t value; uint8_t padding[56]; // 凑满 64B cache line } __attribute__((aligned(64)));每个worker_counter实例独占一条 cache line线程 A 写自己的 value 时不会让线程 B 的 cache line 失效。别小看这一行 padding伪共享修好之后多线程扩展性立刻回归正常。5.5 软件预取最后一个念头别第一眼就扑上去有些朋友看到 cache miss 就想到__builtin_prefetch软件预取我建议把它放在优化清单末尾。原因很现实手写预取需要非常了解内存访问距离距离短了没效果距离长了反而把 cache 污染了而且不同硬件最优预取距离不一样可移植性差。在大多数场景下编译器自动预取和硬件预取器已经做得很好。利用好连续内存访问、调整布局让硬件预取器自然生效比手动插预取指令更可靠。只有当你的访问模式是“已知下一步要访问哪个不连续地址”的稀疏场景比如遍历一个索引数组然后哈希取值软件预取才有发挥空间。6. 验证优化结果并警惕把 cache 调“过头”6.1 优化后复测把数据摆出来v2 版本整理完我按完全相同的环境重新跑perf stat。还是同样的-r 3绑核锁频。汇总数据和 v1 基线对比指标v1 基线v2 优化后变化总耗时1.83 秒0.27 秒下降约 85%IPC1.153.12明显提升cache-misses约 1.6 亿约 1800 万下降约 89%L1-dcache-load-misses约 4.1 亿约 2600 万下降一个数量级这个结果说明优化确实打在了主要矛盾上耗时和 miss 同步下降IPC 提升。v2 的主要改动就是行主序遍历、热冷字段拆分、多线程计数器加了 cache line 隔离并没有引入任何锁或复杂算法。整轮分析的核心逻辑很简单用 perf 量化问题、定位热点、针对性优化、再量化验证。6.2 四个容易误判的坑优化做多了我总结出四个跟 cache 相关的误判几乎每次都能遇到有人踩上去。第一看到 miss 率高就panic。cache miss 不全是坏事也不是所有 miss 都能优化掉。访问随机链表节点、哈希表探测这类本质随机的工作集miss 高是访问模式决定的你只能换数据结构不能靠“多预取”强扭。先判断这个 miss 是否正常。第二只盯 L1 miss忽视 L2/L3 和内存带宽。有些算法 L1 miss 高出天际但 L2/L3 全命中整体并不慢。因为 L3 带宽远高于内存带宽数据只要在 L3 里延迟和带宽都可接受。看全局计数器时三个层级要一起看不要单拿一个 L1 事件说事。第三把调度问题当成 cache 问题。perf stat输出里有一行cpu-migrations如果这个数字很大说明进程频繁迁移cache 内容不断失效。此时你会看到全系统 miss 率虚高但改代码没用先绑核或者优化线程亲和性数据会立刻恢复正常。第四没有看上下文切换。频繁线程切换会让每组 perf 样本都像是“热点散落各处”。context-switches指标很高时先解决锁和 busy-wait再谈 cache 优化。否则你会花大量时间分析根本不存在的热点。6.3 往深了追perf c2c、perf mem、TMA如果优化完还有残余瓶颈可以继续加工具。perf c2c能定位到具体的 cache line 竞争找出哪些地址被多个 CPU 频繁互相失效适合排查伪共享和 NUMA 访问不均衡。perf mem可以对内存访问做采样区分 load 和 store 的延迟来源。再进一步可以用 TMATop-Down Microarchitecture Analysis方法论把 CPU 流水线瓶颈拆成前端、后端、分支预测、等等类别判断瓶颈到底在访存等待还是在执行单元饱和。这些工具不需要一次全上。我的建议是先perf stat全局看方向再perf record抓热点大部分问题到perf annotate就能定位到指令。如果热点都集中在访存相关的指令上cache 布局和伪共享是首选优化方向如果指令本身都解释不了再动 TMA 这类重型工具。最后再分享一个实战中很不起眼但特别有用的习惯每次跑 perf 之前先在代码里打印关键数据结构的sizeof和alignof。很多 cache 问题早在结构体定义的时候就埋下了雷看一眼 64 字节对齐情况比盲跑十轮采样都快。我经手的项目里有一半伪共享问题都是靠这个习惯提前识破的。如果你手头正有个“算法明明不复杂但就是慢”的程序不妨按这篇文章的链路走一遍锁频、绑核、perf stat看基线perf record -e cache-misses抓热点perf annotate看指令。数据说话比拍脑袋加缓存池靠谱得多。
阅读完成 · 觉得有帮助？
