1. 先说清楚lat_mem_rd到底测的是什么内存延迟这个指标做服务端性能优化的人应该都不陌生。但真要说清楚延迟这两个字到底指什么、怎么测才准能讲明白的人其实不多。lat_mem_rd就是用来回答这个问题的工具它是Lmbench测试集里的一个核心成员专门测量处理器访问内存的延迟而且是分层次测的。这句话听起来简单但你真跑过一次就会发现它输出的那张表远比你想象的复杂——纵轴是内存规模横轴是步长中间密密麻麻全是纳秒数。第一次看到这张表的人大概率是懵的。我当年也一样跑完只会看最后一行以为那就是内存延迟后来才搞明白这张表里每一行每一列都有它自己的含义反映的是整个存储层次结构的延迟特性。Lmbench本身是一套非常经典的微基准测试工具集作者是Larry McVoy最早提出微基准测试这个概念的人之一。这套工具涵盖了带宽测试bw_mem、bw_file_rd等、延迟测试lat_mem_rd、lat_rand、lat_pipe等、上下文切换、进程创建、信号处理等一系列操作系统和硬件性能指标的测量。在这些工具里lat_mem_rd是出镜率最高的一个因为内存延迟对数据库、缓存服务、高性能计算这类延迟敏感型应用的影响实在太大了。任何一次CPU访存都要经过L1、L2、L3各级缓存最后才可能落到内存条上每一级的命中与否直接决定了这次访存要花多少个纳秒而lat_mem_rd就是把这些层级的延迟差异一条一条给你量化出来。这篇文章适合谁看一类是做性能分析和系统调优的工程师需要拿它来做基准数据对比另一类是搞底层架构验证的开发者比如内核内存管理、虚拟化、数据库存储引擎开发需要清楚目标平台的内存访问特性。当然如果你只是好奇自己电脑的内存延迟到底是多少拿它跑一下也挺有意思的。接下来我会从工具的原理、参数、输出解读到实战经验把lat_mem_rd讲透。2. 内核原理它怎么做到只测延迟不测带宽lat_mem_rd的测量思路本质上是一个人尽皆知的计算机体系结构常识只要数据在缓存里访问它就快数据不在缓存里访问它就慢。工具要做的就是把数据在不在缓存里这件事控制得足够精确然后计时就够了。2.1 核心逻辑指针追逐与步长遍历lat_mem_rd在内存中维护一个环形链表链表的长度即占用的内存总量由用户指定。测量时处理器从链表头开始通过指针一个个追下去每追到一个节点就算一次访存。关键是链表的节点不一定是连续存放的节点之间的间隔由步长stride参数控制。如果步长设置得很小比如16字节那么整个链表其实是密集排列的大量节点会落在同一个缓存行里数据全部命中L1缓存测出来的延迟就是L1的延迟。当步长变大比如128字节、256字节、512字节链表节点之间的间隔超过了缓存行大小通常是64字节或128字节那么相邻两次访存大概率需要从不同的缓存行取数据。再加上链表总长度也在变大——从4KB到8MB再到64MB——数据逐渐装不进L1、L2、L3越来越多的访问需要去内存里取。于是你就能看到延迟值从几个纳秒一路涨到几十甚至上百纳秒。这是一个非常聪明的设计光靠调整访问规模就能把整个存储层级一步步逼出来。横轴步长改变的是单次访存的局部性纵轴内存规模改变的是整个工作集和缓存容量之间的关系。两个维度叠在一起整张表就是一张存储层次热力图。2.2 排除干扰为什么它能确保测到的是内存延迟纯指针追逐也容易踩坑最大的坑有两个。第一个是硬件预取器的干扰。现代CPU都有非常激进的硬件预取逻辑当你按固定步长遍历内存时预取器很可能会猜到你接下来要访问的地址提前把数据拉到缓存里。这样一来你测到的就不是真实的访存延迟而是预取命中延迟。lat_mem_rd的做法是用随机化来对抗预取——它先把链表节点的顺序随机打乱让访存地址呈现伪随机分布使预取器无法有效预判。当然完全随机也不行因为随机访问的延迟和顺序访问的延迟是有差异的所以lat_mem_rd提供了一些调节手段后面我会细说。第二个是TLB页表缓存的影响。内存访问除了要查缓存还要走地址翻译流程。如果工作集跨越了太多内存页TLB miss会引入额外开销这部分也会被计时器记进去。严格来说lat_mem_rd测的是虚拟地址访存延迟包含了TLB的开销。好在现在的CPU都有多级TLB大页面也能显著降低TLB miss配合2MB/1GB大页使用可以让测出来的延迟更接近物理内存的真实时序这一点在生产环境压测时非常实用。2.3 计时方式与精度问题lat_mem_rd使用高精度时钟来计时在Linux上默认会优先选择clock_gettime(CLOCK_MONOTONIC)这类不受NTP跳变影响的时钟源同时它会对同一规模的测试做多轮重复取最优值或平均值输出。为什么是取最优值因为任何一次上下文切换、中断、调度延迟都会让单次测量产生毛刺取最小值能最接近真实硬件的极限延迟。注意多核机器上跑lat_mem_rd如果进程不被固定在一个核上调度器把进程从一个核移到另一个核L1/L2缓存会整个失效测出来的数值会瞬间暴涨。所以正式测试时一定要用taskset或numactl把进程绑死在某个CPU上。3. 参数拆解与实测输出解读一张表看懂整个存储层级lat_mem_rd的命令行格式不算复杂但每个参数背后都有讲究。默认情况下直接执行./lat_mem_rd就能跑但那是玩具级的用法真要测得准得自己控制参数。3.1 关键参数逐个说明./lat_mem_rd [ -P 并行数 ] [ -W 预热时间 ] [ -N 重复次数 ] 内存规模MB 步长内存规模这是纵轴的上限单位是MB。比如你写./lat_mem_rd 64 128就表示从很小的规模一直测到64MB。工具内部会自动从1KB开始按倍数递增。这个上限要设得比目标平台的L3缓存总容量大不少一般建议至少是L3缓存容量的4到8倍否则最后几行根本体现不出内存的真实延迟。步长单次访问跳过的字节数。常见取值有16、32、64、128、256、512、1024、2048、4096等。步长太小小于缓存行反映的是缓存行内的访问延迟步长大于等于缓存行之后每次访问基本都要加载新缓存行。-P 并行数默认1即单线程测量。多线程模式下多个线程同时跑指针追逐测的是多核并发访问内存时的延迟表现这个值在NUMA架构下意义很大因为跨Node访问和本Node访问的延迟差可以达到数倍。-W 预热时间默认0表示不做预热。预热的作用是让缓存和TLB先进入稳定状态避免冷启动效应。一般建议设置成1到2秒。-N 重复次数温度次数建议至少5次取最优值能有效过滤调度抖动和中断带来的偶发毛刺。3.2 输出表怎么读这是在某颗x86服务器CPUL3约32MB上实测的一段典型输出节选我简化了部分行stride128 0.00098 1.363 0.00195 1.363 0.00391 1.363 0.00781 1.363 ... 0.12500 1.363 0.25000 1.363 0.50000 1.363 1.00000 1.363 2.00000 2.832 4.00000 6.391 8.00000 10.424 16.00000 14.871 32.00000 75.268 64.00000 82.341第一列是内存规模单位MB第二列是延迟单位ns。可以看到从最小规模一直到1MB左右延迟一直稳定在1.363ns附近这说明整个工作集都装进了L1缓存从2MB开始延迟跳到2.8ns说明这之后开始触及L28MB到16MB延迟逐步爬升是L2/L3转换的区域到32MB以后延迟稳定在75ns到82ns级别的这就是真实的内存延迟区间。这里有一个非常关键的观察点延迟值不是平滑上升的而是在某个规模点突然跳变。这个跳变点就对应着某一级缓存的容量边界。比如上面数据里1MB到2MB之间的跳变说明这颗CPU的L1/L2边界就在1MB到2MB之间。结合lscpu或lstopo输出的缓存容量信息就能精确验证体系结构参数。另外stride128这个固定条件下其实只反映了一个切面。你再看stride32、stride512、stride4096等不同步长下的输出会发现完全不同的曲线形状——大stride下延迟会更早开始上升因为它跳过了更多缓存行能用到的缓存容量更少小stride下缓存能装下的数据更多所以延迟的拐点会更靠后。这两组数据叠加在一起才能理解缓存按缓存行管理和按容量管理之间的相互作用。3.3 实测过程中的平台干扰因素跑这个工具最怕的就是平台本身不稳定。频率动态调频DVFS必须关掉否则CPU频率在测试过程中忽高忽低延迟数值完全不可比。建议测之前先固定CPU频率到标称的最高P-state。另外超线程要慎重考虑——如果你用-P 1单线程测试超线程带来的影响有限但如果用-P N多线程测试同一个物理核的两个逻辑核可能会争抢执行单元导致延迟偏高。最稳妥的做法是绑核时避开超线程逻辑核只绑物理核。经验intel平台可以用cpupower frequency-set -g performance固定到performance governorAMD平台同样适用。跑测试前再用turbostat确认实际频率是否维持在目标频率附近这一步花不了几分钟但能省掉后面一堆这数据怎么解释不通的纠结。4. 实战操作流程一次可靠的内存延迟测试该怎么跑纸上谈兵没意思我直接把一套在Linux服务器上经过验证的完整测试流程写出来照着做基本不会翻车。4.1 编译与安装LmbenchLmbench的源码可以从官方GitHub仓库github.com/intel/lmbench拉取Intel维护的这个fork在较新的内核和编译器上都比较干净编译基本一次过。git clone https://github.com/intel/lmbench.git cd lmbench make编译完成后可执行文件会在bin/目录下。如果你在编译时遇到libtinfo相关的报错说明缺少ncurses库安装一下就好# Ubuntu/Debian apt-get install libncurses5-dev # CentOS/RHEL yum install ncurses-devel编译好后建议先跑一下make results看看整套工具是否工作正常它会自动执行一轮标准测试。不过正式性能测试我不建议用make results因为它跑的参数集是通用的未必适合你的目标场景最好还是手动执行lat_mem_rd。4.2 测试前的环境准备这一步的重要性怎么强调都不为过。除了前面说的关闭DVFS还建议做以下几件事关闭NUMA自动均衡——echo 0 /proc/sys/kernel/numa_balancing如果内核开启了自动NUMA均衡的话避免页面在测试过程中被自动迁移。用numactl --hardware确认CPU和内存的拓扑关系如果目标平台是多NUMA节点测试时要明确指定绑在哪个Node上。检查是否有高负载进程抢CPU、抢内存带宽。如果你是在生产环境的宿主机上测建议用stress-ng或systemd-run起一个隔离环境或者干脆找一台空闲机器测。内存容量要足够lat_mem_rd虽然只占用你指定的内存规模但如果同时还有其他大内存应用在跑可能会触发swap那就全乱套了。4.3 推荐的命令行组合以一台L3为32MB的双路x86服务器为例我常用的测试命令是这样的export OMP_NUM_THREADS1 taskset -c 10 ./lat_mem_rd -P 1 -W 1 -N 5 256 128解释一下几个参数-P 1单线程这是最标准的延迟测量方式。-W 1预热1秒让缓存和TLB进入状态。-N 5每档规模跑5次取最优值。256内存规模上限设为256MB远大于32MB的L3能完整覆盖到内存延迟。128步长设为128字节意味着每次访存至少跨越两个缓存行64B为例能有效避开缓存行内部访问的干扰。taskset -c 10把进程绑定到核心10上避免迁移抖动。等它跑完输出会全部打印在终端上。如果想存成文件方便后续分析直接重定向就行taskset -c 10 ./lat_mem_rd -P 1 -W 1 -N 5 256 128 lat_mem_rd_256m_stride128.log如果你还想看不同步长下的表现差异可以用一个简单循环批量跑for stride in 16 32 64 128 256 512 2048 4096; do taskset -c 10 ./lat_mem_rd -P 1 -W 1 -N 5 256 $stride result_${stride}.log; done这样跑出来的一组文件就是一份相当完整的内存访问延迟画像。4.4 结果的分析与归档跑完以后我一般会做两件事。第一把每份log里规模-延迟的对应关系抽出来画成曲线图横轴内存规模用对数坐标纵轴延迟。图上你会很直观地看到几个平台期和几个跳变点每个跳变点就是一个缓存层级边界。第二把所有stride的结果放在一起对比观察步长对延迟拐点的影响。这一步能帮你判断缓存行大小、TLB行为是否符合预期。顺手贴一段我用awk快速提取数据的命令可以一键把规模-延迟两列抽出来awk NF2 {print $1, $2} lat_mem_rd_256m_stride128.log如果你的测试目标是为了跟其他机器横向对比那一定要保证两台机器的测试环境一致——不只是同样的参数还包括同样的内核版本、同样的CPU频率设置、同样的NUMA拓扑利用方式。否则你对比的就是两个完全不同条件下的数据结论很容易失真。4.5 大页与虚拟化环境下的特殊处理如果你跑在虚拟机里或者通过配置大页来优化性能的数据库服务器上默认的4KB页会让TLB开销显著变大延迟数值也会受影响。建议测试时挂载hugepage并用LD_PRELOAD或者显式通过libhugetlbfs让进程使用hugepage这样才能测出应用在真实生产配置下的访存延迟。具体操作是这样的# 预留2MB大页假设要预留512个 echo 512 /proc/sys/vm/nr_hugepages mkdir -p /mnt/huge mount -t hugetlbfs nodev /mnt/huge # 然后通过LD_PRELOAD让lat_mem_rd使用大页 LD_PRELOAD/usr/lib64/libhugetlbfs.so HUGETLB_MORECOREyes ./lat_mem_rd -P 1 128 128这个配置在云服务器上尤其有用因为云平台的虚拟CPU往往TLB更小4KB页下的TLB miss率会更高测出来的延迟数据会比物理机明显偏高。用上大页之后数据和物理机对比时才有参考价值。5. 常见问题与排查技巧实录那些年踩过的坑lat_mem_rd本身是一个极简工具功能非常专一但正因为简单任何一点环境干扰都会直接反映在数据上。我把这几年实际使用中碰到的问题整理成一个速查表希望能帮你少走弯路。5.1 典型问题与解决方案速查现象可能原因排查与解决方案延迟值整体偏高且波动极大进程在测试过程中被调度到不同核心用taskset绑定固定核确认未使用超线程核检查是否有cgroup限制小规模数据延迟就大于10ns步长设置过大单次访问跨多页TLB miss严重调小stride到64/128或启用hugepage延迟曲线没有明显平台期全程猛涨DVFS/频率降频固定性能模式用turbostat确认频率两次测试同一档位数值差几倍中断、内核线程干扰或相邻核心跑满用chcpu关掉相邻核心的负载或用irqbalance --banirq屏蔽中断推荐跑多次取最小值最后几行延迟反而下降工作集超过内存控制器交错粒度后部分访问命中DRAM row buffer正常现象不必惊慌说明你已经触达了内存控制器的优化路径虚拟机上数值明显偏高虚拟化层带来的影子页表/EPT开销对比物理机时应使用大页或嵌套页表优化单纯看数值要注明虚拟化环境多线程模式下延迟比单线程高一截内存带宽争用、缓存一致性开销正常现象用-P 2/4做并发延迟对比测试记录带宽限制下的延迟变化5.2 最容易被忽略的两个实操细节第一个是步长和缓存行的关系。如果你的CPU缓存行是64字节而你选stride32那么两次相邻访问可能落在同一个缓存行里测出来的延迟是缓存行内命中的延迟并不是真实跨越缓存行的访存延迟。很多初学者在这里栽了跟头跑完看到延迟很低以为自己的内存很快其实是测错了对象。在不确定缓存行大小的情况下先用getconf LEVEL1_DCACHE_LINESIZE或者lscpu -C查一下再选步长。一般建议选缓存行大小的2倍以上比如64B缓存行就选128B步长。第二个是测试内存规模必须远大于最后一级缓存。很多人跑./lat_mem_rd 8 128L3一测发现只有30多ns就以为机器的内存延迟是30ns这明显是把L3延迟当成了内存延迟。判定标准很简单观察输出的最后几行看延迟值是否已经趋于稳定。如果还在逐步上升说明规模不够大继续加大内存规模重测。理想的输出最后一段应该是一条接近水平的直线那才是真正的内存延迟。5.3 作为一个性能分析工具它的边界在哪里lat_mem_rd测的是单线程、指针追逐场景下的访存延迟它反映的是硬件的极限能力而不是你应用的真实访问模式。实际业务里访存通常是混合的——有顺序读、随机读、写、读写混合还有多核并发。所以lat_mem_rd的结果适合用来回答这台机器的存储层次结构是什么样和硬件极限在哪里这类问题但要评估一个真实应用的性能表现还需要结合带宽测试bw_mem、随机延迟测试lat_rand、以及应用级的benchmark一起看。另外提醒一句不少云厂商在宣传文档里会引用某一个特定配置下的lat_mem_rd数据这些数据只能作为参考别直接拿来做选型依据。因为云厂商的机型、虚拟化层、CPU型号、NUMA拓扑都可能影响结果最靠谱的做法还是自己拿到实例后用同样的方法实测一遍。5.4 一个实战案例用lat_mem_rd定位NUMA访问性能差异有一年我给一套数据库系统做性能压测发现同样一条只读SQL在实例A上跑得飞快在实例B上偶尔会慢20倍。系统监控里CPU、IO都看不出异常。后来我分别在两个实例上跑了numactl --hardware和lat_mem_rd发现实例B的延迟表在规模超过本地内存容量后出现了一个明显的延迟台阶——从80ns跳到了160ns。再一查原来是这台机器上数据库的numa策略配错了内存被分配到了远端Node。把numa策略改成interleaveall后延迟直接回落慢查询也随之消失。这个案例想说明的是lat_mem_rd的输出不只是给人看的参考数字它完全可以当作系统级问题的定位信号。延迟表里每一个台阶、每一个异常爬升背后都有对应的硬件或系统配置原因。花点时间看懂这张表等于给自己添了一个非常灵敏的底层性能探针。6. 如何把lat_mem_rd的结果用到实际优化里聊完了原理和操作最后说点更偏向工程实践的内容——测出延迟之后怎么把它转化成有用的决策依据。6.1 用延迟曲线辅助算法和数据结构选型内存延迟直接决定了某些数据结构的上限。举个例子如果你知道这台机器L2缓存延迟只有4nsL3延迟约15ns内存延迟80ns那么在设计和选择哈希表、B树这类对随机访问敏感的数据结构时心里就有了一本账只要工作集能压进L2随机查询的单次开销大约就是4ns级别一旦工作集超过L2掉到内存里去单次开销立刻跳到80ns以上性能差距是20倍。这个数量级的差距靠算法微调是无法弥补的只能靠重新设计数据布局来改变访问局部性。我之前做过一个索引模块的优化就是把原来一个很大的哈希索引拆成了两级热数据放在一个紧凑的小哈希表里让它始终驻留L2缓存冷数据放在大哈希表里。改造前后用lat_mem_rd的数据来估算理论上随机点查能加快近10倍实测确实从90ns左右降到了15ns以内。如果不是先有lat_mem_rd给出的量化依据这个优化方案很难说服团队投入精力去做。6.2 把延迟测试纳入日常性能回归体系如果你所在的团队维护着多台不同配置的服务器或者你经常需要评估新采购硬件的性能那强烈建议把lat_mem_rd跑成一套标准脚本纳入日常性能回归流程。比如每台新机器上线前都跑一轮把结果归档每次内核升级后跑一轮对比升级前后的延迟变化每次BIOS/固件更新后也跑一轮。这套做法的好处是当线上真的出现性能问题时你手里有一份这台机器原本应该是什么水平的基线数据。否则你面对一个数据库突然变慢的告警得从几百项系统指标里大海捞针而有了基线第一时间就能对内存延迟的特征做对比快速圈定问题范围。一个比较实际的小技巧把lat_mem_rd和stream带宽测试一起跑延迟和带宽两个维度一起看。因为有时候延迟没变但带宽降了或者反过来这两个指标分别受到不同硬件环节的影响组合起来能更快定位是缓存问题、内存控制器问题还是NUMA互连问题。6.3 长期观察同一台机器不同内核版本下的延迟差异我在维护一些跑数据库的老机器时统计过几次内核升级前后的lat_mem_rd数据。有时候内核自带的页表管理、TLB冲刷策略、NUMA均衡策略调整后确实会在延迟数据上反映出来——不是那种几纳秒的细微波动而是某个规模点的跳变位置会移动或者特定规模下的延迟值出现几个纳秒的稳定偏移。这些变化不代表硬件有问题也不代表内核变差了而是说明内核的内存管理策略变了应用程序感受到的访存延迟随之变化。对于延迟敏感型应用这种微妙的变化可能会被放大到业务层面所以做内核升级时拉一组基线数据对比是非常值得的。写在最后的一个小提醒在我个人使用lat_mem_rd的这些年里最大的心得是它测出来的数字不重要数字背后的趋势和边界才重要。单看一个81ns说明不了任何问题但当你看到延迟从L2的4ns跳到L3的15ns再跳到内存的80ns每一级跳变都对应着你程序里数据在不同层级间的迁移——这时候你才算真正懂了自己的系统。如果你手头正好有台Linux机器不妨现在就试着跑一下./lat_mem_rd 128 128对照CPU缓存容量表亲手把那个延迟台阶找出来。这个过程花不了十分钟但你对内存延迟这四个字的理解会在这一刻变得具体而扎实。