Linux内存带宽测试工具stream：原理、编译与跑分避坑指南

简介：STREAM（Simple 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 都是读两个数组、写一个数组。它们之间的差异只在于读写的比例和一点计算量，恰好覆盖了工程负载里最常见的访存模式。

下表是四个内核的访存特征：

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_SIZE=4000000即可。如果你不想每次查缓存大小，也可以直接用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/s；DDR5-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|Locator"

lscpu看物理核心数和 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_SIZE=80000000 -DNTIMES=20 stream.c -o stream

逐项说明：-O3开启最高级别优化，对 stream 这种循环密集型代码是必须的，不带优化的 stream 分数会低 15% 以上；-fopenmp开启 OpenMP 多线程支持，否则只能用单核跑，成绩会惨不忍睹；-DSTREAM_ARRAY_SIZE=80000000用编译宏覆盖源码里默认的 2,000,000，这个值代表每个数组的元素个数，四个数组共 8,000 万 × 8 字节 × 4 = 2.56GB，对主流服务器已经足够测到真实内存带宽；-DNTIMES=20把重复次数设为 20，降低偶然性。

-march=native这个参数要不要加？它可以让编译器针对当前 CPU 指令集做优化，本机自测可以加。但要注意：加了它编译出的二进制不能拿到别的机器上跑，跨机型对比时最好统一用最基础的-O3编译，或者全部使用同一个二进制文件。

如果你手头有 Intel 编译器，也可以试：

icx -O3 -qopenmp -DSTREAM_ARRAY_SIZE=80000000 -DNTIMES=20 stream.c -o stream_intel

gcc 和 Intel 编译器开出来的分数可能差 2% 到 5%，这不代表硬件差异。做对比测试时，所有机器必须用同一个编译器、同一份参数，否则结论不可信。

3.2 跑分前的运行时设置：线程数、绑核与内存绑定

编译好之后不要直接./stream就完事。先看这台机器的拓扑，再决定怎么跑：

lscpu numactl --hardware

numactl --hardware会列出 NUMA 节点编号、每节点可用的 CPU 范围和内存大小。Linux 下内存分配默认是 first-touch 策略，哪个线程先访问某段内存，页面就落在哪个 NUMA 节点上。如果不对线程做绑定，OpenMP 的线程可能在运行中漂移到其他核心，导致一部分访存变成跨节点访问，带宽掉一截。

单台单路服务器最小正确运行方式是：

export OMP_NUM_THREADS=16 numactl --cpunodebind=0 --membind=0 ./stream

OMP_NUM_THREADS=16要设置成物理核心数，而不是逻辑线程数。超线程对 stream 这种带宽饱和型负载几乎没提升，有时候还会帮倒忙。--cpunodebind=0限定线程只跑在 NUMA node 0 的 CPU 上，--membind=0强制内存分配只从该节点的内存控制器走，彻底避免远端访存。

如果你的机器是 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 远端访问

现象：同一个二进制文件，连续跑三次 stream，Triad 分数波动超过 8%，有时候甚至更高。

原因：没做绑核时，Linux 调度器会在测试过程中把 OpenMP 线程挪到别的物理核心上。特别在多路服务器上，线程一旦跨 NUMA 节点，内存访问就要经过远端内存控制器，延迟变高、带宽打折。

解决：用numactl --cpunodebind和--membind绑死，再配合 OpenMP 自带的线程亲和性参数：

export OMP_NUM_THREADS=16 export OMP_PROC_BIND=true numactl --cpunodebind=0 --membind=0 ./stream

加OMP_PROC_BIND=true后，OpenMP 会把线程固定到一组核心上，不再漂移。跑分出现波动时，先加上这两个参数再看结果。

4.3 线程数翻倍成绩反而下降：超线程不是免费午餐

现象：16 物理核 32 逻辑线程的机器上，把OMP_NUM_THREADS从 16 改成 32，Triad 分数没有提升，反而下降了几个百分点。

原因：stream 是带宽饱和型负载，内存控制器的排队已经打满，超线程逻辑核并不能带来更多内存带宽，只会增加调试器上的调度开销和缓存争用。

解决：把OMP_NUM_THREADS设置成物理核心数，而不是逻辑线程数。查看物理核数的命令是：

lscpu | grep "^CPU(s):" lscpu | grep -E "Core|Thread|Socket" # 确认物理核和超线程比例

如果你的业务中 stream 只是参考，实际应用能吃满超线程，那服务器上继续开超线程没问题，但 stream 跑分时别拿逻辑线程数当线程数。

4.4 不同机器分数不可比的隐藏原因：编译参数和数组大小不一致

现象：用别人给的 stream 二进制或者不同编译参数跑出来的分数，和自己机器上对比，结论和 CPU 型号强弱完全对不上。

原因：-O2和-O3有差距，加不加-march=native有差距，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-cpus=0-7 --memory=32g -e OMP_NUM_THREADS=8 -v /path/stream:/stream stream /stream/stream

即使这样绑了，结果也只能作为相对参考，不能作为物理机内存带宽的验收依据。想把虚拟化平台的性能摸清楚，应该在宿主机物理环境直接测。

5. 多路服务器与 NUMA 下的 stream 细调：从绑核到编译参数

5.1 多路服务器的标准测法：按 NUMA 节点分开测，再看整机聚合

多路服务器的正确打开方式是先分节点测。因为每个 NUMA 节点本地带宽才是最干净的硬件能力，跨节点测出的是远端访问能力，两者混在一起很难定位问题。

下面是一个可复用的分节点测试脚本：

#!/bin/bash # 每个 NUMA 节点的物理核数，以 2 路 32 物理核机器为例就是 16 PER_NODE_CORES=16 export OMP_NUM_THREADS=$PER_NODE_CORES export OMP_PROC_BIND=true 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_BIND=true让线程固定位置。PER_NODE_CORES需要按实际拓扑手动改，避免线程数超过节点核心数导致排队。

整机聚合测试不需要绑单节点，但建议用内存交错模式：

export OMP_NUM_THREADS=32 numactl --interleave=all ./stream

--interleave=all让内存页在多个节点间轮询分配，避免所有数据堆在节点 0 上。这样测出的整机 Triad 才是多路内存控制器的联合带宽。在 2 路机器上，整机分数通常接近单节点分数的两倍；如果明显低于两倍，检查跨节点互连配置和内存通道是否均衡。

5.2 编译宏和 OpenMP 运行变量的细调：数组大小、调度方式与绑定策略

STREAM_ARRAY_SIZE 到底设多大，取决于测试目的。下表是快速验收和深度测试的参考取值：

取值的核心原则只有一个：数组总大小必须远大于最后一级缓存。超过 4 倍之后，带宽数据已经基本稳定，继续加大只会延长测试时间。我习惯在 64MB LLC 的机器上设STREAM_ARRAY_SIZE=80000000，四数组 2.56GB，既稳又不至于跑太久。

OpenMP 运行变量也有几个值得固定。OMP_SCHEDULE=static可以让循环分块在启动时一次分配，避免动态调度带来的运行期开销；OMP_PROC_BIND=true配合OMP_PLACES=cores可以把线程固定在物理核心上。完整的一组推荐是：

export OMP_NUM_THREADS=32 export OMP_PROC_BIND=true export OMP_PLACES=cores export OMP_SCHEDULE=static numactl --cpunodebind=0 --membind=0 ./stream

OMP_PLACES=cores告诉 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 节点各跑一遍，再跑一遍整机--interleave=all。第四步，把 Triad 数值和效率记录到一个固定的表格里。

表格可以很简单：

跑分前确认系统空闲，先看top或mpstat有没有明显占用。测试期间不要做其他 IO 操作，避免干扰。如果时间和条件允许，同一配置跑两轮，取稳定的一轮记录。效率低于 70% 时不要急着下结论，重跑一次，再检查内存实际频率和通道数量。

我自己养成的习惯是：每台新服务器到手，先跑一遍 stream 固化成基线文件，之后每次内存报错、降频或者性能劣化，都拿同一个二进制复测。这个习惯帮我快速定位过两次内存降频和一次通道没插满的问题——完全是 stream 给的答案，不需要玄学。希望帮到你。

本文还有配套的精品资源，点击获取