简介STREAMSimple Triad Memory Benchmark是业界评估内存带宽的经典基准测试工具由John D. McCalpin博士开发常用于Linux环境下内存控制器、缓存层次结构与总线性能的分析。该资源面向系统优化工程师、性能测试人员及硬件爱好者提供完整源码包。压缩包共8个文件大小17KB包含C与Fortran源码stream.c、stream.f及mysecond.c、Makefile构建脚本、README说明文档、LICENSE与HISTORY等历史记录结构清晰便于直接编译运行或修改测试参数。已有2960人学习下载。通过Copy、Scale、Add、Triad四种典型操作可量化持续内存带宽为系统调优、硬件选型或科学计算场景提供可靠参考数据。资源体积小、无复杂依赖适合快速部署于各类Linux发行版也可作为学习内存性能测试方法的入门蓝本。1. Linux 内存性能测试工具 stream 到底在测什么先看这个数值是否可信在 Linux 服务器上验收内存子系统内存性能测试工具 stream 几乎是绕不开的默认选项。它测的不是 CPU 跑多快也不是内存条上印刷的频率而是 CPU 持续读写内存这条通路上的真实带宽——科学计算、数据库缓冲、HPC 节点选型时这个数值比频率字段更能说明问题。很多人第一次跑 stream 会懵为什么 Copy、Scale、Add、Triad 四个分数不一样为什么标称 DDR4-3200 双通道的机器跑出来的数字和理论峰值差一截这篇笔记按“原理 — 编译 — 跑分 — 避坑 — 验收”的顺序把一个可信的 stream 流程讲清楚。适合运维、HPC 负载调优和做服务器采购验收的人照着复现。2. 拆开 stream 的四个内核Copy/Scale/Add/Triad 的读写模式与理论带宽2.1 stream 的四个内核到底在做什么计算stream 的核心只有四个循环简单到让人怀疑它凭什么能测内存带宽。它分别叫 Copy、Scale、Add、Triad完整源码里就是四个计算模式// 标准 stream.c 里的四个内层循环示意省略 OpenMP 指令和计时器 // COPY: a[i] b[i] for (j 0; j STREAM_ARRAY_SIZE; j) a[j] b[j]; // SCALE: a[i] q * b[i] for (j 0; j STREAM_ARRAY_SIZE; j) a[j] q * b[j]; // ADD: a[i] b[i] c[i] for (j 0; j STREAM_ARRAY_SIZE; j) a[j] b[j] c[j]; // TRIAD: a[i] b[i] q * c[i] for (j 0; j STREAM_ARRAY_SIZE; j) a[j] b[j] q * c[j];四个循环都遍历三个 double 数组每个元素 8 字节。当数组大到无法被 CPU 缓存装下时每一次读和写都要真实地走到内存控制器。Copy 是读一个数组、写一个数组Scale 同样读一写一但带一个乘法Add 和 Triad 都是读两个数组、写一个数组。它们之间的差异只在于读写的比例和一点计算量恰好覆盖了工程负载里最常见的访存模式。下表是四个内核的访存特征内核读数组数写数组数计算量典型用途Copy11无内存拷贝、缓冲区搬运Scale11一次乘法向量缩放Add21一次加法向量相加Triad21一次乘加矩阵/科学计算最常用模式Triad 之所以常被当作宣传分数是因为它最接近很多真实代码的形态先读两个操作数做一次乘加写回一个结果。而 Copy 是最纯粹的读写测试能直接反映内存控制器的原始吞吐。同一个机器上这四个值会有差异差异幅度本身也是硬件对不同读写比例响应的一种体现。2.2 STREAM_ARRAY_SIZE、NTIMES 与“持续带宽”的定义stream 只做一件事让 CPU 不停地把数组读进来、写出去。但如果数组太小数据就会留在最后一级缓存里测出来的是 L3 带宽而不是内存带宽。STREAM_ARRAY_SIZE 默认值只有 2,000,000四个数组加起来一共 64MB在一台 LLC 为 32MB 或 64MB 的服务器上这个尺寸很容易命中缓存成绩会虚高到 150GB/s 以上看起来“强得离谱”。官方注释明确要求 STREAM_ARRAY_SIZE 至少要比最大缓存大数倍常见的经验值是至少 4 倍。具体换算公式是STREAM_ARRAY_SIZE (LLC 字节数 × 4) / 8 字节例如一台 CPU 的 L3 缓存是 32MB那么 4 倍是 128MB每个数组 32MB元素数就是 32MB / 8B 4,194,304编译时写-DSTREAM_ARRAY_SIZE4000000即可。如果你不想每次查缓存大小也可以直接用getconf LEVEL3_CACHE_SIZE拿到 LLC 字节数再套公式。另一个参数是 NTIMES它控制同一轮测试重复几次。stream 会重复执行同一批循环并记录每次耗时输出里会有 Min time、Max time 和 Avg time。NTIMES 太小偶然一次调度延迟就可能污染结果太大则白白拉长测试时间。我一般快速验收用 10做稳定对比用 20。数组很大时 10 次也足够因为单次运行时间已经很长。这里需要理解“持续带宽”的含义stream 测的不是内存瞬时峰值而是长时间、大数组、流水线式读写能维持的带宽。真正需要对比的是 Best Rate但 Best Rate 是按 Min time 算出来的代表“最好的一次”不是“平均表现”。如果 Avg time 和 Min time 相差很大说明测试期间系统不稳定这个分数不能直接拿来宣传。2.3 理论带宽怎么算频率、通道数与 stream 的实际效率跑分之前先算理论峰值否则看到数字也不知道好坏。内存带宽的公式是理论带宽 内存频率(MT/s) × 8 字节 × 通道数注意 DDR 的频率单位是 MT/s每秒百万次传输不是 MHz。一次传输 64 bit也就是 8 字节。DDR4-3200 双通道就是 3200 × 8 × 2 51.2 GB/sDDR5-4800 八通道就是 4800 × 8 × 8 307.2 GB/s。实际 stream 成绩通常只有理论值的 70% 到 90%。DDR4 成熟平台跑出 85% 以上很正常DDR5 早期平台低一些也很正常。如果你跑出来的效率连 60% 都不到先别怪 CPU按下面几个最可能的方向查内存实际频率有没有被 BIOS 降频、通道有没有插满、OpenMP 线程数够不够、线程是不是漂移到了远端 NUMA 节点。在 Linux 上查这些配置几个常用的命令就能搞定lscpu | grep -E Socket|Core|Thread|NUMA dmidecode -t memory | grep -E Size|Speed|Locatorlscpu看物理核心数和 NUMA 拓扑dmidecode -t memory看每条内存的容量、标注速度和插槽位置。注意Speed字段有时显示的是内存 SPD 里的标称值不是当前实际运行的频率真正确认当前频率要看 BIOS 或者系统日志。理论峰值先按“实际运行频率 × 真的插满的通道数”来算这个预期值才靠谱。3. 用 stream 在本地跑出可信带宽源码编译、运行命令与输出解读3.1 获取 stream.c 并给出最小编译命令stream 是单文件 benchmark源码公开从官网的 Code 目录下载stream.c就行。离线环境里把这个文件保存到自己的版本库后续所有机器都用同一份源码编译这是保证横向可对比的第一步。拿到源码后最小可用编译命令是tar -xzf stream.c.tar.gz # 解压到源码目录 gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE80000000 -DNTIMES20 stream.c -o stream逐项说明-O3开启最高级别优化对 stream 这种循环密集型代码是必须的不带优化的 stream 分数会低 15% 以上-fopenmp开启 OpenMP 多线程支持否则只能用单核跑成绩会惨不忍睹-DSTREAM_ARRAY_SIZE80000000用编译宏覆盖源码里默认的 2,000,000这个值代表每个数组的元素个数四个数组共 8,000 万 × 8 字节 × 4 2.56GB对主流服务器已经足够测到真实内存带宽-DNTIMES20把重复次数设为 20降低偶然性。-marchnative这个参数要不要加它可以让编译器针对当前 CPU 指令集做优化本机自测可以加。但要注意加了它编译出的二进制不能拿到别的机器上跑跨机型对比时最好统一用最基础的-O3编译或者全部使用同一个二进制文件。如果你手头有 Intel 编译器也可以试icx -O3 -qopenmp -DSTREAM_ARRAY_SIZE80000000 -DNTIMES20 stream.c -o stream_intelgcc 和 Intel 编译器开出来的分数可能差 2% 到 5%这不代表硬件差异。做对比测试时所有机器必须用同一个编译器、同一份参数否则结论不可信。3.2 跑分前的运行时设置线程数、绑核与内存绑定编译好之后不要直接./stream就完事。先看这台机器的拓扑再决定怎么跑lscpu numactl --hardwarenumactl --hardware会列出 NUMA 节点编号、每节点可用的 CPU 范围和内存大小。Linux 下内存分配默认是 first-touch 策略哪个线程先访问某段内存页面就落在哪个 NUMA 节点上。如果不对线程做绑定OpenMP 的线程可能在运行中漂移到其他核心导致一部分访存变成跨节点访问带宽掉一截。单台单路服务器最小正确运行方式是export OMP_NUM_THREADS16 numactl --cpunodebind0 --membind0 ./streamOMP_NUM_THREADS16要设置成物理核心数而不是逻辑线程数。超线程对 stream 这种带宽饱和型负载几乎没提升有时候还会帮倒忙。--cpunodebind0限定线程只跑在 NUMA node 0 的 CPU 上--membind0强制内存分配只从该节点的内存控制器走彻底避免远端访存。如果你的机器是 2 路或 4 路最简单的做法是先对每个 NUMA 节点分别跑一遍再跑一遍不绑定的全机测试。小节的最后会给出一个可复用脚本手工一条条敲也可以。3.3 读懂 stream 输出Best Rate、Min time 与 MB/s 的换算跑完后输出大致长这样Function Best Rate MB/s Avg time Min time Max time Copy: 41234.1 0.412345 0.410001 0.433211 Scale: 40123.8 0.423456 0.421234 0.452123 Add: 43156.7 0.394000 0.390123 0.423456 Triad: 42567.9 0.398000 0.395123 0.412345每一行里面Best Rate MB/s才是你需要的带宽数字。它的计算方式是以 Copy 为例一次 Copy 需要读一个双精度数组、写一个双精度数组总流量是 2 × 8 字节 × STREAM_ARRAY_SIZE再乘以 NTIMES最后除以最小耗时。这个 MB 用的是十进制1 MB 1,000,000 字节不是 1 MiB 1,048,576 字节。很多人在这个细节上栽过跟头对比厂商宣传值时容易差 5%。Avg time是 NTIMES 次的平均耗时Min time是最快一次Max time是最慢一次。Best Rate 按 Min time 计算所以它代表的是“这台机器状态最好时的带宽”。如果 Min time 和 Max time 差距超过 10%说明测试期间有中断、调度或者内存争用建议重跑。四个内核之间的相对关系也有参考价值Copy 通常是最高的因为读写各一次Add 和 Triad 读写比例相同数值会接近Scale 比 Copy 略低也正常。如果你看到 Copy 明显低于 Add先回去检查线程绑定和 NUMA 设置。另外一个值得注意的点新版 stream 会在输出末尾校验计算结果。如果你为了速度加了-ffast-math这类激进优化导致校验失败那跑分再高也不能用因为它已经不是标准 stream 了。做对比时千万不要用这种参数。4. stream 跑分的 5 个经典翻车场景现象、原因与修复4.1 成绩高得像假分数STREAM_ARRAY_SIZE 没改测到的是缓存现象在一台只有 DDR4 双通道的机器上默认编译直接跑Copy 分数飙到 150GB/s 甚至更高远超理论带宽。原因STREAM_ARRAY_SIZE 没改四个数组总共 64MB数据块大部分落在最后一级缓存里CPU 用缓存带宽在“骗”你。解决先查 LLC 容量再按至少 4 倍体积重编译。getconf LEVEL3_CACHE_SIZE # 输出单位是字节 # 假设输出 33554432也就是 32MB # 4 倍 LLC 128MB 总数组每个数组 32MB # STREAM_ARRAY_SIZE 32MB / 8 字节 4194304修正后如果分数回落到理论带宽的 80% 左右说明之前就是缓存命中导致的虚高。以后看到跑分高得离谱第一反应不是“机器真猛”而是“数组是不是太小了”。4.2 连续两次跑分差 8%线程漂移和 NUMA 远端访问现象同一个二进制文件连续跑三次 streamTriad 分数波动超过 8%有时候甚至更高。原因没做绑核时Linux 调度器会在测试过程中把 OpenMP 线程挪到别的物理核心上。特别在多路服务器上线程一旦跨 NUMA 节点内存访问就要经过远端内存控制器延迟变高、带宽打折。解决用numactl --cpunodebind和--membind绑死再配合 OpenMP 自带的线程亲和性参数export OMP_NUM_THREADS16 export OMP_PROC_BINDtrue numactl --cpunodebind0 --membind0 ./stream加OMP_PROC_BINDtrue后OpenMP 会把线程固定到一组核心上不再漂移。跑分出现波动时先加上这两个参数再看结果。4.3 线程数翻倍成绩反而下降超线程不是免费午餐现象16 物理核 32 逻辑线程的机器上把OMP_NUM_THREADS从 16 改成 32Triad 分数没有提升反而下降了几个百分点。原因stream 是带宽饱和型负载内存控制器的排队已经打满超线程逻辑核并不能带来更多内存带宽只会增加调试器上的调度开销和缓存争用。解决把OMP_NUM_THREADS设置成物理核心数而不是逻辑线程数。查看物理核数的命令是lscpu | grep ^CPU(s): lscpu | grep -E Core|Thread|Socket # 确认物理核和超线程比例如果你的业务中 stream 只是参考实际应用能吃满超线程那服务器上继续开超线程没问题但 stream 跑分时别拿逻辑线程数当线程数。4.4 不同机器分数不可比的隐藏原因编译参数和数组大小不一致现象用别人给的 stream 二进制或者不同编译参数跑出来的分数和自己机器上对比结论和 CPU 型号强弱完全对不上。原因-O2和-O3有差距加不加-marchnative有差距STREAM_ARRAY_SIZE大小也有差距。任何一项不一致跑分都不是同一个 benchmark。解决做对比测试前把三件事统一同一份 stream.c 源码、完全相同的编译命令、相同的 STREAM_ARRAY_SIZE 和 NTIMES。并且所有机器跑同一个二进制不要在 A 机器编译后拿到 B 机器说这是 B 的成绩。还有一条铁律不要在编译参数里加-ffast-math它可能改变最终校验结果让 stream 失去标准意义。4.5 虚拟机和容器里测的 stream 能不能信现象在虚拟化平台或容器里跑 stream分数有时比物理机高有时只有物理机的 70%而且每次迁移宿主机后结果都会变。原因虚拟机的 vCPU 是分时调度的内存 balloon 会动态调整分配给虚拟机的内存宿主机超售时其他虚拟机抢内存带宽这些都会直接影响 stream 结果。容器里如果没限制 CPU 范围线程会在宿主机的物理核心间漂移同样导致带宽不稳定。解决硬件验收必须物理机跑虚拟机里的 stream 只能用于“同一个虚拟机前后改动对比”。容器里跑需要绑定 vCPU 范围并让 OpenMP 线程数匹配容器可用核数docker run --cpuset-cpus0-7 --memory32g -e OMP_NUM_THREADS8 -v /path/stream:/stream stream /stream/stream即使这样绑了结果也只能作为相对参考不能作为物理机内存带宽的验收依据。想把虚拟化平台的性能摸清楚应该在宿主机物理环境直接测。5. 多路服务器与 NUMA 下的 stream 细调从绑核到编译参数5.1 多路服务器的标准测法按 NUMA 节点分开测再看整机聚合多路服务器的正确打开方式是先分节点测。因为每个 NUMA 节点本地带宽才是最干净的硬件能力跨节点测出的是远端访问能力两者混在一起很难定位问题。下面是一个可复用的分节点测试脚本#!/bin/bash # 每个 NUMA 节点的物理核数以 2 路 32 物理核机器为例就是 16 PER_NODE_CORES16 export OMP_NUM_THREADS$PER_NODE_CORES export OMP_PROC_BINDtrue NODES$(ls -d /sys/devices/system/node/node* | wc -l) for n in $(seq 0 $((NODES-1))); do echo NUMA node $n numactl --cpunodebind$n --membind$n ./stream done脚本里--cpunodebind$n限制线程只能跑在节点 n 的 CPU 上--membind$n强制内存从该节点分配OMP_PROC_BINDtrue让线程固定位置。PER_NODE_CORES需要按实际拓扑手动改避免线程数超过节点核心数导致排队。整机聚合测试不需要绑单节点但建议用内存交错模式export OMP_NUM_THREADS32 numactl --interleaveall ./stream--interleaveall让内存页在多个节点间轮询分配避免所有数据堆在节点 0 上。这样测出的整机 Triad 才是多路内存控制器的联合带宽。在 2 路机器上整机分数通常接近单节点分数的两倍如果明显低于两倍检查跨节点互连配置和内存通道是否均衡。5.2 编译宏和 OpenMP 运行变量的细调数组大小、调度方式与绑定策略STREAM_ARRAY_SIZE 到底设多大取决于测试目的。下表是快速验收和深度测试的参考取值测试目的数组大小参考四数组总占用说明快速验收4 × LLC 字节数 ÷ 84 × LLC满足官方最低要求跑得快常规测试16 通道 × 8 字节约为 LLC 的 16 倍16 × LLC更稳妥避免临界缓存容量深度压力物理内存的 1/4 分配给四个数组内存容量 × 1/4对内存控制器压力更大耗时明显变长取值的核心原则只有一个数组总大小必须远大于最后一级缓存。超过 4 倍之后带宽数据已经基本稳定继续加大只会延长测试时间。我习惯在 64MB LLC 的机器上设STREAM_ARRAY_SIZE80000000四数组 2.56GB既稳又不至于跑太久。OpenMP 运行变量也有几个值得固定。OMP_SCHEDULEstatic可以让循环分块在启动时一次分配避免动态调度带来的运行期开销OMP_PROC_BINDtrue配合OMP_PLACEScores可以把线程固定在物理核心上。完整的一组推荐是export OMP_NUM_THREADS32 export OMP_PROC_BINDtrue export OMP_PLACEScores export OMP_SCHEDULEstatic numactl --cpunodebind0 --membind0 ./streamOMP_PLACEScores告诉 OpenMP 把线程分布在独立的物理核上而不是超线程逻辑核上。这四个变量组合是 stream 跑分稳定性的关键比反复调整编译命令作用更大。5.3 用 stream 发现内存降频和通道配置问题把跑分当成体检工具stream 除了当基准还能快速暴露内存硬件的异常状态。有一次我接手一台标称 8 通道 DDR5 的服务器Triad 只跑到理论值的 50%查了半天才发现 BIOS 里内存训练失败整机降频到 DDR5-3600 运行带宽自然缩水。遇到分数明显偏低时按这个顺序查dmidecode -t memory | grep -E Size|Speed|Locator # 看插槽是否插满、标称频率多少 lscpu | grep -E Socket|NUMA # 看节点拓扑 cat /proc/meminfo | grep -E MemTotal|HugePages # 排除大页配置影响通道是否插满最容易忽略。标注支持 8 通道的主板如果只插了 4 根内存条即便每条频率正常带宽也直接减半。stream 对通道数极其敏感减一根通道立刻能看出来。内存降频和通道失效这类问题最麻烦的是平时很难察觉。CPU 占用率正常、内存容量不变、系统不报错只有带宽跑不满。stream 的价值就在于它是一个可以留档的体检工具新机器到货时记录一组 baseline存放好二进制文件和运行脚本之后再测直接对比。如果某次 Triad 掉了 10% 以上基本可以确定是内存频率、通道或 NUMA 配置出了问题。6. 用 stream 给新服务器做内存验收记录基线才能谈好坏把 stream 固化成验收动作比临时跑一次看数字有意义得多。我的做法是四步第一步开机后先查内存规格按第 2 章的公式算出理论带宽。第二步用统一的编译参数生成二进制并把这个二进制和运行脚本一起存档。第三步分 NUMA 节点各跑一遍再跑一遍整机--interleaveall。第四步把 Triad 数值和效率记录到一个固定的表格里。表格可以很简单机器内存规格理论带宽实测 Triad效率备注节点 ADDR4-3200 双通道51.2 GB/s44.1 GB/s86%通过节点 BDDR4-3200 双通道51.2 GB/s36.8 GB/s72%BIOS 降频需检查跑分前确认系统空闲先看top或mpstat有没有明显占用。测试期间不要做其他 IO 操作避免干扰。如果时间和条件允许同一配置跑两轮取稳定的一轮记录。效率低于 70% 时不要急着下结论重跑一次再检查内存实际频率和通道数量。我自己养成的习惯是每台新服务器到手先跑一遍 stream 固化成基线文件之后每次内存报错、降频或者性能劣化都拿同一个二进制复测。这个习惯帮我快速定位过两次内存降频和一次通道没插满的问题——完全是 stream 给的答案不需要玄学。希望帮到你。本文还有配套的精品资源点击获取