6.1 NUMA架构别让你的CPU“舍近求远”NUMA全称是非统一内存访问架构。说白了就是每个CPU有自己的“本地内存”访问起来快访问别人的内存就得绕路慢不少。我在项目中遇到过一台48核的服务器跑数据库业务性能死活上不去。查了半天发现一半的CPU都在访问远端内存。延迟多了几十纳秒积少成多吞吐量直接腰斩。核心原则让线程尽量访问它所在NUMA节点上的内存。怎么判断当前系统是不是NUMA架构用这个命令# 查看NUMA拓扑 numactl --hardware # 输出示例 available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 node 0 size: 32768 MB node 1 cpus: 4 5 6 7 node 1 size: 32768 MB node distances: node 0 1 0: 10 20 1: 20 10看到那个“node distances”了吗访问本地内存延迟是10远端是20。差了一倍。避坑指南我曾经在绑定CPU亲和性时只绑了CPU核心没绑内存分配策略。结果线程在node 0上跑内存却从node 1分配。性能反而更差了。记得加上numactl --membind0。6.2 内存带宽别让数据“堵车”内存带宽就是内存和CPU之间的“车道宽度”。车道窄了数据就得排队。现代CPU的内存带宽看着挺高比如DDR5能到几十GB/s但实际应用中很容易跑满。我印象很深的一次是优化一个视频编解码服务。CPU利用率才30%但帧率就是上不去。用perf stat一看内存带宽利用率到了95%。# 查看内存带宽使用情况需要root perf stat -e uncore_imc/data_reads/,uncore_imc/data_writes/ -a -- sleep 1 # 或者用更直观的工具 # 安装pip install pcm pcm-memory.x内存带宽瓶颈的典型特征CPU利用率不高但性能上不去多个核心同时访问内存时延迟急剧增加程序有明显的“内存拷贝”密集型操作注意内存带宽是共享资源。一个核心跑满带宽其他核心都得等着。我见过有人把日志缓冲设成4MB每次写日志都刷一遍内存直接把带宽吃光了。优化思路其实就两条减少数据搬运——能复用就复用别反复拷贝提高缓存命中率——数据尽量留在CPU缓存里少去内存6.3 TLB缺失被忽视的“隐形杀手”TLB翻译过来是“页表缓存”。CPU要访问一个内存地址得先查页表把虚拟地址转成物理地址。这个转换结果就缓存在TLB里。TLB很小一般只有几十到几百个条目。为什么会出问题你想想看如果程序访问的内存范围很大TLB里放不下每次都得去内存里查页表。一次TLB缺失代价是几十到几百个周期。我调过一个内存数据库数据量100GB随机访问。TLB缺失率高达5%。别小看这5%每次缺失多花100个周期整体性能就掉了5%以上。# 用perf查看TLB缺失 perf stat -e dTLB-load-misses,iTLB-load-misses ./your_program # 输出示例 # 1,234,567 dTLB-load-misses # 234,567 iTLB-load-missesTLB缺失分两种类型原因典型场景数据TLB缺失dTLB数据访问的地址转换不在TLB中大数据集随机访问、内存映射文件指令TLB缺失iTLB指令获取的地址转换不在TLB中代码体积大、函数分散、JIT编译我的经验如果dTLB缺失高优先考虑大页内存。如果iTLB缺失高试试把热点函数放到同一个代码段里或者用__attribute__((section(.text.hot)))。6.4 大页内存一招解决TLB缺失大页内存就是把默认的4KB页换成2MB甚至1GB的页。页变大了同样大小的内存区域需要的页表条目就少了TLB能覆盖的内存范围就大了。举个例子一个程序需要访问2GB内存。用4KB页需要 2GB / 4KB 524,288 个页表条目用2MB大页只需要 2GB / 2MB 1,024 个条目TLB一般只有64个条目。用4KB页64个条目只能覆盖256KB内存。用2MB大页64个条目能覆盖128MB。差距有多大一目了然。启用大页内存有两种方式# 方式一透明大页THP自动管理 echo always /sys/kernel/mm/transparent_hugepage/enabled # 方式二手动预留大页 echo 1024 /proc/sys/vm/nr_hugepages # 然后程序通过mmap使用 mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);警告透明大页虽然方便但有时会导致内存碎片和延迟抖动。我曾在数据库服务器上遇到因为THP引发的性能毛刺关了之后稳定多了。关键业务建议手动管理大页。大页内存适合的场景大数据集应用数据库、搜索引擎、内存缓存频繁随机访问的工作负载对延迟敏感的服务不适合的场景小内存应用大页浪费内存频繁分配释放内存的程序大页分配慢内存占用动态变化大的场景最后说一句内存优化没有银弹。NUMA、带宽、TLB、大页这四个维度要结合起来看。我一般会先用perf stat扫一遍看看瓶颈到底在哪再针对性下手。别一上来就开大页先搞清楚问题是什么。总结一下我的优化检查清单检查NUMA拓扑确保线程和内存在同一节点监控内存带宽利用率别让数据堵在路上用perf看TLB缺失率超过1%就要重视TLB缺失高试试大页内存立竿见影嗯内存这块就聊到这儿。内容不少但都是实战里摸爬滚打出来的经验。你下次遇到性能问题不妨先从内存入手看看。
