Linux内存性能测试工具STREAM：从四项基准到避坑指南-北京尧图网络

简介内存带宽是服务器性能评估中常被忽视的基础指标尤其当CPU占用不高而吞吐受限时瓶颈往往隐藏于内存子系统。STREAM作为Linux生态中最经典的内存性能测试工具通过Copy、Scale、Add、Triad四项基准循环以量化内存带宽的方式为性能分析和硬件选型提供依据。其原理在于构造远超缓存容量的数组访问迫使数据在主存与CPU之间流动从而反映真实内存能力。正确使用STREAM需要理解编译参数、NUMA绑核与数组大小设定并结合perf缓存未命中率、多次复测取中位等手段验证结果有效性。无论是服务端调优、硬件对比还是团队基线建设STREAM都能快速给出可复现的内存带宽数据帮助定位瓶颈并避免缓存作弊带来的虚假高分。1. 先说结论Linux 内存性能测试工具 stream为什么性能分析总得先跑一遍它去年某次压测模拟项目X 的 CPU 占用率只有三成吞吐却怎么也上不去排查到最后才发现是内存带宽先见底了。那次经历让我养成一个习惯凡是碰性能瓶颈先在 Linux 上跑一遍 stream。stream 是 Linux 生态里最经典的内存性能测试工具用 Copy、Scale、Add、Triad 四项基准把整机内存带宽量化出来一分钟就能拿到结论。它适合三类人做服务端性能优化时想确认瓶颈在 CPU 还是内存选型新硬件时想横向比一比内存子系统以及面试或带新人时需要一个可复现的内存基线测试。切忌拿默认参数上去就跑每项参数都有讲究后面逐个拆开讲。2. stream 测的到底是什么四个基准与“走出缓存”的算计2.1 四个基准的访存模式Copy、Scale、Add、Triad 各自的负载特征stream 不是单个测试是四个独立循环。源码核心逻辑可以等价理解为下面这段 C 代码注意数组都是 double 类型每个元素 8 字节// 核心循环N 由编译期宏指定 double a[N], b[N], c[N]; double scalar 3.0; int j; // Copy最纯粹的读-写 for (j 0; j N; j) a[j] b[j]; // Scale同一数组读改写 for (j 0; j N; j) a[j] scalar * a[j]; // Add两个读一个写 for (j 0; j N; j) c[j] a[j] b[j]; // Triad混合读乘加写最接近真实负载 for (j 0; j N; j) a[j] b[j] scalar * c[j];Copy 模拟的是一半读一半写的线性流是最理想的内存搬运模型Scale 在同一个数组上做读改写会触发 cache line 的状态转换跟 Copy 的读-写路径不完全一样Add 是典型的两读一写适合考察多读场景Triad 在 Add 基础上加了一个标量乘法内存控制器看到的还是两读一写但 CPU 侧指令数变多更贴近数据库扫描、图像处理这类实际负载。四项数字落在同一量级才有参考意义单项特别高或特别低都要怀疑。内存控制器视角的字节数值得单独列一张表因为 stream 结果里的 MB/s 就是按“操作字节数 / 耗时”算出来的基准每次迭代涉及数组数每次迭代搬运字节数8 字节/元素读:写Copy216 字节1:1Scale2同一数组读写16 字节1:1Add324 字节2:1Triad324 字节2:1scalar 那个乘法因子常驻寄存器不算访存流量。表格里最容易被忽略的是Copy 和 Scale 虽然都只有 16 字节但 Scale 针对同一个数组写回时 cache line 要先读进来再改状态转换更频繁所以实测经常比 Copy 略低几个百分点这是正常现象。2.2 数组大小为什么要“大得让缓存装不下”stream 的陷阱在于如果 N 太小四个基准的数组在 L1/L2/L3 里就能跑完测到的是缓存带宽而不是内存带宽。缓存带宽通常是内存带宽的几倍到十几倍数字会漂亮得没有参考价值。行业里的通行做法是让数组总占用至少超过最大缓存容量的 10 倍。# 先查处理器缓存配置 lscpu | grep -i cachelscpu 输出的 L3 是全核共享的最后一级缓存N 的计算基准就靠这一行。假设 L3 是 32MB数组总占用为 3 × N × 8 字节要让总占用达到 320MB 以上N 至少取 13,000,000 左右。我一般会取一个余量更大的整值比如 N80000000对应总占用约 1.92GB在 8GB 以上内存的机器上都不会碰到内存不足的问题。如果数组大到把物理内存吃光系统开始换页结果就直接废了——后面避坑章节会细说。折中原则是数组总占用不超过物理剩余内存的一半同时大于 L3 的 10 倍。这两个条件同时满足测出来的才是真实的内存带宽。2.3 NTIMES 与计时逻辑为什么结果表同时给 Min Time 和 Max Time每个基准循环要执行 NTIMES 次常见默认值是 10 或 20目的是避免单次被中断、调度、温度变化干扰。计时的关键是取最小值而不是平均值Min time 代表系统在最好情况下的真实能力Avg time 代表统计期望Max time 则暴露抖动。如果同一次运行里 Min 和 Max 差出 20% 以上说明测量环境不干净后台可能有编译任务、日志落盘或者监控采集在抢带宽。结果表里的 Best Rate MB/s 就是用前面那张表的操作字节数除以 Min time 得到的。跑之前先看剩余内存已经算半个行业习惯了free -h这行命令本身没有技术含量但它能拦住一大批“跑一半开始换页”的无效测试。内存不足时 stream 不会报错只是时间悄悄变大不会有人怀疑结果有问题。3. 编译与参数设定一条 gcc 命令行决定结果可信度3.1 取源码与确认版本stream 的源码是一个单文件 stream.c网上公开的基准测试源码页基本都能找到。把它放在独立工作目录里避免和项目代码混在一起mkdir -p ~/benchmark cd ~/benchmark # 从 STREAM 基准测试公开源码页获取 stream.c并确认文件完整 ls -l stream.c head -n 5 stream.chead 命令看的是文件头的版本说明stream.c 不同小版本的宏定义有差异比如数组长度宏在部分版本里叫 N较新版本支持 STREAM_ARRAY_SIZE。我后面统一用 STREAM_ARRAY_SIZE 写法如果你的版本只认 N把宏名换回去就行语义一样。3.2 基础编译为什么默认参数直接跑不可信# 最基础的编译适合先确认工具本身能跑 gcc -O3 -DSTREAM_ARRAY_SIZE80000000 -DNTIMES20 stream.c -o stream-O3 是必须的优化级别。stream 是带宽型测试如果不优化标量代码连内存请求都发不满测出来的数字低得离谱代表不了真实能力。STREAM_ARRAY_SIZE 是数组元素个数80000000 对应总占用约 1.92GB前面已经算过。NTIMES 是重复次数取 20 是为了让 Min time 更有统计意义如果 N 调到几亿一次循环就要好几秒20 次会等很久我一般会降到 5 到 10。这里有一个常见的认知误区开了优化就可能被编译器改写。stream 源码本身带有防优化手段比如把引用数组暴露给外部、阻止循环被整体消除。这套防护不是万能的所以工程上还有一道手续需要时加下面这个选项防止循环被改写成优化的库函数调用gcc -O3 -fno-tree-loop-distribute-patterns -DSTREAM_ARRAY_SIZE80000000 -DNTIMES20 stream.c -o stream-fno-tree-loop-distribute-patterns 的作用是禁止 GCC 把循环识别成 memcpy、memset 一类的模式并整体替换掉。一旦循环被替换成高度优化的库函数访存模式就偏离了 stream 设计的模板测出来的是库函数性能而不是内存子系统性能。这个选项专业工具链里经常出现属于踩过坑之后记住的编译参数。3.3 OpenMP 多核版本内存带宽要靠多个核一起发请求才能打满单核发内存请求的速度在大多数服务器上是看不出来真实带宽的需要多核并发把内存控制器的队列打满。# 多线程编译 gcc -O3 -fopenmp -fno-tree-loop-distribute-patterns -DSTREAM_ARRAY_SIZE80000000 -DNTIMES20 stream.c -o stream_omp # 运行前设置线程数取物理核心数 export OMP_NUM_THREADS8 export OMP_PROC_BINDtrue export OMP_PLACEScores ./stream_ompOMP_NUM_THREADS 设成 8 是因为这台机器有 8 个物理核心。内存带宽负载下不要超过物理核心数超线程的虚拟核心不会增加有效内存请求反而可能因为资源竞争拖低成绩。OMP_PROC_BINDtrue 把线程固定在核心上OMP_PLACEScores 指定按物理核心而不是超线程逻辑处理器来分配位置这两个环境变量组合能避免调度器把线程迁来迁去线程迁移会带来 TLB 和末级缓存的额外开销。3.4 NUMA 机器上的绑核策略测本地还是测整机要先想清楚现在的多路服务器默认是 NUMA 架构每个 CPU 连接一部分物理内存跨节点访问要走互联总线带宽掉一半是很正常的事。# 查看 NUMA 拓扑 lscpu | grep -A3 NUMA跑 stream 之前先明确一个问题你测的是某个业务进程在 node0 上的表现还是整机内存子系统的峰值如果答案是前者用下面的命令把线程和内存都钉在 node0numactl --cpunodebind0 --membind0 ./stream_ompcpunodebind0 把所有线程约束到节点 0 的 CPU 上membind0 把内存分配也约束到节点 0这是最严格的本节点测试。如果目标是整机峰值就不加 membind让内核按照默认策略在多个节点间平衡分配这时候 OMP_NUM_THREADS 要相应放大到覆盖两个节点的物理核心总数。3.5 一次完整运行流程与结果判读实际工程里我不会只跑一遍而是用一个最小脚本串起来顺便留下原始日志#!/bin/bash # 先确认环境是干净的 free -h | head -2 lscpu | grep -E Model name|L3|NUMA node ulimit -s unlimited # 编译无 OpenMP 版本 gcc -O3 -fno-tree-loop-distribute-patterns \ -DSTREAM_ARRAY_SIZE80000000 -DNTIMES20 \ stream.c -o stream # 连续跑三次并保留完整输出 for i in 1 2 3; do echo run $i ./stream done | tee stream_result.logulimit -s unlimited 是保险措施虽然 stream.c 的数组是静态全局区分配但不同修改版可能把数组放在栈上不放开栈上限会直接段错误。三次运行主要看 Triad 的 Best Rate 波动如果三次相差超过 5%说明系统里有周期性负载这时候别说测出来的数值准连参考意义都存疑。运行结束后的输出大约长这样------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 38240.5 0.693200 0.689253 0.696400 Scale: 38177.2 0.694730 0.690852 0.699100 Add: 41945.6 0.946120 0.940253 0.952300 Triad: 42033.4 0.944780 0.938253 0.951300 -------------------------------------------------------------这是某 x86_64 服务器在双通道内存下的合理量级。注意特征是 Copy 与 Scale 接近Add 与 Triad 略高一点——读多写少的负载对内存控制器更友好。如果 Copy 明显高于 Triad甚至高出百分之二三十大概率不是内存真实能力强而是数组大小没设够数据在缓存里“作弊”了。4. 避坑指南为什么你的 stream 结果跑不出参考值4.1 数组太小L3 缓存里跑出的“虚假高分”现象Copy 轻松跑到 200GB/s 以上明显超过内存理论带宽而且怎么调 NTIMES 都稳定在这个量级。原因数组总占用没有盖过 L3循环主体在缓存里搬运。L3 带宽通常是内存带宽的好几倍测出来当然好看但这份报告没法用于性能分析和硬件选型。解决先 lscpu 查 L3再按「3 × N × 8 字节 ≥ L3 × 10」反推 N 下限。比如 L3 是 32MBN 至少往 13,000,000 以上放我习惯直接给到 80,000,000一劳永逸。改完宏重新编译带宽会立刻回到合理区间那种“捡到宝”的分数基本都会消失。4.2 编译器自作聪明循环被改写后测的就不是内存了现象开 -O3 编译后 Copy 和 Scale 分数异常高Add 与 Triad 又明显偏低四项之间的比值完全乱掉。原因GCC 在某些版本会做循环分布和模式识别把 stream 的循环改写成更激进的库函数调用或重新组织访存顺序。访存模式一旦偏离指定模板结果就无法解释。解决保留 -O3但在编译命令里显式加 -fno-tree-loop-distribute-patterns。如果还不行对照一下源码的注释确认防优化开关没被注释。偶尔会遇到某个编译器版本对 stream 特别不友好这时候换一个 GCC 小版本重编比硬调参数更省时间。编译器优化对 stream 来说本来就是半玄学踩过坑之后我习惯把头文件里与优化相关的宏先过一遍再跑。4.3 NUMA 远端访问测到的不是本地内存带宽现象同一份二进制第一次跑 40GB/s第二次变成 25GB/s或者在 node0 上好好的换个调度位置分数掉一半。原因多路服务器的跨节点访问要经过互联总线带宽上限远低于本地内存节点。stream 默认绑核策略不明确时线程和内存可能落在不同节点跑出来的是混合带宽。解决明确测试目标后绑定。测单节点用 numactl --cpunodebind0 --membind0测整机时让线程覆盖所有物理核心同时用 OMP_PROC_BINDtrue 固定位置避免执行过程中线程被调度器搬走。判断是否真的有远端访问可以用 numastat 看各节点的内存分配量分配不均衡就去查启动脚本里的 cgroup 或亲和性设置。4.4 物理内存不足触发 swap时间被磁盘吃掉了现象Max time 比 Min time 大出两三倍甚至某些循环耗时突然暴涨到几十秒Best Rate 波动大复现性极差。原因数组总占用超过物理内存剩余量系统开始换页。stream 的数组本来就是为了把内存打满一旦触发 swap访问延迟从纳秒级变成毫秒级读盘时间全算进测试耗时里。解决跑之前 free -g 确认剩余内存数组总占用控制在剩余内存的一半以内。32GB 机器我常用 N80,000,000约 1.92GB 占用剩下的空间留够系统缓存和后台进程。另外确认下 swap 本身有没有被其他服务占用用 free 看 swap 一行的 used 值不为零时最好先停掉可疑任务。4.5 后台任务抢带宽测的是别人而不是机器现象白天跑 35GB/s深夜跑 41GB/s同一台机器同一份二进制结果每次都差几个百分点。原因日志采集、数据库刷盘、编译任务都可能占用内存带宽。stream 测的是“当下剩余带宽”不是“理论最大带宽”任何并发读写都会压低分数。解决跑之前用 top 或 pidstat 清点进程测试期间暂停重负载服务。定期复测的话固定在同一业务低峰时段比如凌晨两点到四点误差会小很多。这个坑最不容易被察觉因为结果表看起来永远正常只是数值悄悄变小。提示如果最终目的只是对比两台机器的内存能力最重要的事情不是追求分数绝对值而是确保两台机器用同一份 stream.c、同一个编译命令、同一套绑核策略。参数不一致时分数差异说明不了任何问题。5. 交叉验证与复测让一次 stream 结果真正能写进报告5.1 用 perf 验证数据是否真的来自内存perf stat -e cache-misses,cache-references ./streamcache-references 是缓存访问次数cache-misses 是未命中次数。数组设计合理的情况下stream 的 miss 占比应该接近 100%因为它故意制造缓存外流量。如果 miss 率只有六七成说明还有相当一部分数据在 L3 里发挥余热测出来的带宽仍然偏乐观。这一条是判断结果有效性的硬指标我每次跑完都会顺手加一句 perf 数据进报告。5.2 三次复测取中位数的习惯内存带宽测试最怕偶发中断单次 Min time 可能有运气成分。我一般用五轮复测取中位#!/bin/bash LOGstream_verify.log : $LOG for i in 1 2 3 4 5; do echo round $i $(date %T) | tee -a $LOG ./stream_omp 21 | tee -a $LOG done # 抽 Triad 的 Best Rate 排序取中位 grep Triad: $LOG | awk {print $2} | sort -n | \ awk {a[NR]$1} END{print Triad median MB/s:, a[int((NR1)/2)]}这段脚本把五轮 Triad 分数取出来排序取中间值而不是平均值能剔除极端抖动。awk 的 int((NR1)/2) 在偶数轮次时偏向上中位工程上够用真要严谨可以自己再加偶数个判断。5.3 对照理论带宽判断效率区间理论峰值等于内存传输率乘总线位宽。以常见双通道内存为例传输率 2666MT/s、每次传输 16 字节时理论带宽约 42.6GB/s。stream 的 Triad 落在 70% 到 90% 的效率区间也就是 30 到 38GB/s 左右都算正常。低于 60% 先排查绑核和数组大小高于 100% 基本可以断定缓存介入。报告里我把实测值、理论值、效率百分比三行放在一起别人看起来不用再自己折算。那次默认参数跑出 210GB/s 还写进结项报告的经历让我很长一段时间不敢轻信任何没经过交叉验证的带宽数据。从那以后我每次跑 stream 都强制走一遍「lscpu 查缓存 → 算 N → perf 看 miss 率 → 五轮复测取中位」的流程翻车率降了不少。希望帮到你。本文还有配套的精品资源点击获取

Linux内存性能测试工具STREAM：从四项基准到避坑指南

相关推荐

IDA MCP本地AI逆向：语义分析六层架构与零认证设计

Oracle与MySQL数据库巡检最快检查清单：十分钟定位实例、连接与容量风险

PHP+MySQL安全实战：SQL注入、跨库查询与文件读写防护指南

更多资讯

Token是什么？NLP、认证、区块链、编译器中的四种含义与边界

豆瓣评论情感分析实战：SnowNLP清洗、校准与TF-IDF词云

专科生论文降AI率实战指南：检测原理与9个工具组合用法

并查集与贪心：破解情侣牵手的最小交换次数

重言式判别程序设计：从表达式树到真值表的完整实现

用Python从零复现KCF目标跟踪算法：原理、实现与避坑指南

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？