4. 性能观测工具链

内存性能，说白了就是整个系统的粮草运输线。CPU 算得再快，如果内存供不上数据，那也是白搭。我这些年调优过的系统，十有八九的瓶颈都卡在内存上，而不是 CPU 本身。

今天咱们就把内存这层窗户纸捅破。从硬件层次结构讲起，再到缓存、TLB、带宽和延迟，每个点我都会结合实战经验来说。

内存层次结构：为什么 CPU 需要那么多级缓存？

先看一张图，这是我每次培训都会画的。它解释了为什么现代 CPU 要搞出 L1、L2、L3 这么复杂的缓存体系。

内存层次结构图 内存层次结构：速度与容量的权衡 CPU 核心 L1 Cache (32KB ~ 64KB) ~1ns L2 Cache (256KB ~ 1MB) ~4ns L3 Cache (8MB ~ 32MB) ~15ns 主存 (DRAM) ~100ns 磁盘 / SSD ~10⁶ns 核心规律： • 越靠近 CPU，速度越快 • 越靠近 CPU，容量越小 • 成本呈指数级上升 延迟差距： L1 比主存快 100 倍 主存比 SSD 快 10000 倍

你想想看，CPU 主频已经到 3-5GHz，一个时钟周期才 0.2-0.3 纳秒。但去主存拿数据要 100 纳秒，这中间差了 300 多个周期。CPU 只能干等着。所以缓存就是用来填这个坑的。

我个人习惯把缓存看作「数据的热区」。程序访问内存是有规律的，这叫局部性原理。时间局部性：刚用过的数据很快还会再用。空间局部性：刚用过的数据附近的数据也快被用到。

关键认知：缓存不是万能的。如果你的数据访问模式是随机跳跃的，缓存命中率会惨不忍睹。我曾经优化过一个数据库查询，把随机 IO 改成顺序扫描后，吞吐量翻了 8 倍。原因就是缓存命中率从 20% 提到了 95%。

缓存命中率：性能的分水岭

缓存命中率，就是 CPU 在缓存里找到想要数据的概率。这个指标直接决定了你的程序是「飞」还是「爬」。

咱们用 perf 工具来实测一下。这是我在一台 Xeon 服务器上跑过的例子：

# 测量 L1 缓存命中率
perf stat -e L1-dcache-loads,L1-dcache-load-misses ./my_app

# 输出示例
 1,234,567,890  L1-dcache-loads
   123,456,789  L1-dcache-load-misses   # 10% 缺失率

# 测量 LLC (L3) 命中率
perf stat -e LLC-loads,LLC-load-misses ./my_app

# 输出示例
   456,789,012  LLC-loads
    91,357,802  LLC-load-misses   # 20% 缺失率

看到没？L1 缺失率 10%，L3 缺失率 20%。这意味着每 10 次内存访问，就有 1 次要穿透到 L2，每 5 次就有 1 次要走到主存。这个程序的性能还有很大优化空间。

实战经验：我一般把 L1 缺失率控制在 5% 以内，L3 缺失率控制在 10% 以内，才算「及格」。如果 L3 缺失率超过 20%，那就要警惕了——你的程序很可能在频繁访问主存，性能会断崖式下跌。

缓存行与伪共享：一个容易被忽视的坑

缓存不是按字节存的，是按「缓存行」存的。现代 CPU 的缓存行大小通常是 64 字节。也就是说，你读一个 4 字节的 int，CPU 会把相邻的 60 个字节也一起拉进来。

这本来是个好事——利用空间局部性。但多线程场景下，它可能变成噩梦。这就是「伪共享」。

举个例子：

// 伪共享的典型例子
struct Data {
    int thread1_counter;  // 线程1 频繁写
    int thread2_counter;  // 线程2 频繁写
    // 这两个变量很可能在同一个缓存行里
};

// 优化方案：缓存行对齐
struct Data {
    int thread1_counter;
    char padding[60];  // 填充到 64 字节
    int thread2_counter;
    char padding2[60];
};

我曾经在一个高并发网关项目里遇到过这个问题。两个线程各自更新自己的计数器，结果性能死活上不去。用 perf 一看，L1 缺失率高达 40%。加了 padding 之后，缺失率降到 3%，吞吐量直接翻倍。

注意：伪共享不会导致数据错误，只会导致性能灾难。两个线程修改不同变量，但它们在同一个缓存行里，CPU 的缓存一致性协议会让这个缓存行在两个核心之间反复失效、重载。你想想看，这得多浪费。

TLB 缺失：虚拟地址翻译的瓶颈

TLB（Translation Lookaside Buffer）是 CPU 用来加速虚拟地址到物理地址翻译的缓存。说白了，它就是页表的「快照」。每次内存访问，CPU 都要把虚拟地址翻译成物理地址，这个翻译过程如果走页表，代价很高。

TLB 缺失分两种：

  • 指令 TLB 缺失（ITLB miss）：取指令时发生。常见于代码体积大、跳转频繁的场景。
  • 数据 TLB 缺失（DTLB miss）：访问数据时发生。常见于大数据集、随机访问的场景。

用 perf 看 TLB 很简单：

# 测量 DTLB 缺失
perf stat -e dTLB-loads,dTLB-load-misses ./my_app

# 输出示例
 987,654,321  dTLB-loads
  49,382,716  dTLB-load-misses   # 5% 缺失率

TLB 缺失率超过 1% 就要注意了。超过 5% 就是严重问题。为什么？因为一次 TLB 缺失可能要花费几十到几百个周期去查页表。

优化思路：TLB 缺失的克星是「大页」。默认的页大小是 4KB，TLB 只能缓存几十到几百个条目。如果你用 2MB 的大页，同样的 TLB 条目数可以覆盖 512 倍的内存空间。我调优过一个内存数据库，启用大页后，TLB 缺失率从 8% 降到了 0.3%，查询延迟降低了 40%。

启用大页的方法：

# 查看当前大页配置
cat /proc/meminfo | grep HugePages

# 临时启用 2MB 大页（需要 root）
echo 1024 > /proc/sys/vm/nr_hugepages

# 程序中使用大页（mmap 时指定 MAP_HUGETLB）
void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
                 MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);

内存带宽与延迟：两个不同的维度

很多人把带宽和延迟混为一谈。其实它们是两个完全不同的性能指标。

指标 定义 典型值 瓶颈场景
带宽 单位时间内能传输的数据量 DDR4: 20-50 GB/s
DDR5: 40-80 GB/s		 大块数据拷贝、矩阵运算、视频处理
延迟 从发出请求到收到数据的时间 L1: ~1ns
L2: ~4ns
主存: ~100ns		 随机访问、指针追逐、数据库查询

用 lmbench 可以实测带宽和延迟：

# 测量内存延迟
./lat_mem_rd 128 1024
# 输出：128MB array, 1024 stride: 87.6ns

# 测量内存带宽
./bw_mem 256M rd
# 输出：256MB read: 12500 MB/s

我的经验：带宽瓶颈通常可以通过「数据分块」和「向量化」来缓解。延迟瓶颈则要靠「预取」和「缓存友好」的数据结构。比如把链表换成数组，把随机访问改成顺序访问。我优化过一个图算法，把邻接表从链表改成压缩稀疏行（CSR）格式后，延迟降低了 70%。

实战：用 perf 定位内存瓶颈

最后，我分享一个实战套路。当你怀疑内存是瓶颈时，按这个步骤来：

  1. 先看整体：perf stat -e cycles,instructions,cache-misses,cache-references ./app。如果 cache-misses/cache-references 超过 10%，进入下一步。
  2. 细分缓存层级：perf stat -e L1-dcache-load-misses,LLC-load-misses ./app。定位是 L1 还是 L3 的问题。
  3. 检查 TLB：perf stat -e dTLB-load-misses,iTLB-load-misses ./app。如果超过 1%，考虑大页。
  4. 看带宽：perf stat -e uncore_imc/data_reads/,uncore_imc/data_writes/ ./app。如果接近硬件上限，考虑数据分块。
  5. 采样分析：perf record -e mem_load_retired.l3_miss -c 1000 ./app。找到具体是哪些代码触发了 L3 缺失。

嗯，这套流程我用了好多年，基本没有失手过。内存性能优化，说白了就是让数据尽量待在离 CPU 近的地方。你把这个原则刻在脑子里，遇到问题就不会慌。

← 上一章 📖 返回目录 下一章 →