简介本资源是Linux系统内存性能基准测试工具STREAM的完整源码包面向系统管理员、性能工程师及底层开发人员用于精准评估服务器或工作站的内存带宽与数据吞吐能力尤其适用于大数据分析、科学计算等对内存子系统敏感的场景。压缩包为17KB的ZIP格式共8个文件含核心实现文件stream.c与mysecond.cC语言主逻辑、stream.fFortran版本、Makefile一键编译支持、README与HISTORY.txt使用说明与演进记录、.gitignore及LICENSE.txt结构精简、开箱即用。目前已有2973人学习下载体现了其在性能调优领域的广泛实践基础。用户可直接编译运行获取Copy/Scale/Add/Triad四类内存操作的实测带宽MB/s结合源码深入理解内存访问模式与缓存行为同时为跨平台对比、硬件选型及内核参数调优提供可靠基准依据。1. Stream 不是“流媒体”而是内存带宽的照妖镜为什么你的高性能计算节点跑不满标称带宽你刚部署完一台搭载 DDR5-4800 的双路服务器理论内存带宽标称 153.6 GB/s但跑完 HPL、HPCG 等标准基准后实际应用吞吐总卡在 90–110 GB/s 区间GPU 显存带宽跑得飞起CPU 内存却像被掐住脖子——这时候别急着怀疑 BIOS 设置或 NUMA 绑定先用stream跑一发。它不测延迟、不压缓存、不模拟业务逻辑就干一件事用最朴素的 C 数组循环榨干 CPU 到内存控制器之间的物理通路极限。很多团队直到上线半年后才第一次运行stream结果发现——标称带宽根本没被触达不是代码写得差是硬件链路本身存在隐性瓶颈内存插槽配对错误、CL 时序未收敛、IMC集成内存控制器电压不足、甚至主板 PCB 走线阻抗失配。stream就是那个不讲情面的“内存带宽体检仪”它不关心你用的是 OpenMP 还是 MPI只认地址对齐、访存模式、编译器向量化能力这三样硬指标。适合所有做 HPC、AI 训练底座调优、数据库内存密集型负载部署的一线工程师新手靠它建立对“真实带宽”的直觉老手靠它快速定位硬件交付异常。它不是万能的但凡stream跑不出 85% 以上标称值后续所有上层性能优化大概率是在修漏水的桶。2. 从源码编译到四核并行用 stream 在本地跑通内存带宽测试的最小命令2.1 下载与编译为什么必须自己编译而不是用包管理器安装stream官方源码由 John D. McCalpin 博士维护长期托管在 https://www.cs.virginia.edu/stream/ 最新稳定版为stream_v5.10.c截至 2024 年中。切勿使用apt install stream或yum install stream安装的版本——这些包通常来自第三方仓编译参数固化如固定-O2、禁用 AVX-512、未定义STREAM_ARRAY_SIZE且无法控制线程绑定策略测出来的是“发行版妥协后的带宽”不是你机器的真实能力。我们采用手动编译核心目标有三个① 启用最高级向量化AVX2/AVX-512② 控制数组大小确保完全驻留于主存避开 L3 缓存干扰③ 绑定到指定 CPU 核心排除调度抖动。# 创建工作目录并下载源码注意必须用 curl -L 获取重定向后的真实地址 mkdir -p ~/stream-test cd ~/stream-test curl -L -O https://www.cs.virginia.edu/stream/FTP/Code/stream.c # 重命名为更清晰的文件名并设置关键宏定义 mv stream.c stream_v5.10.c # 编译命令关键参数逐个说明 gcc -O3 -marchnative -fopenmp -DSTREAM_ARRAY_SIZE200000000 \ -DNTIMES10 -DSTREAM_TYPEfloat stream_v5.10.c -o stream_omp_float参数说明-O3启用激进优化对循环展开和向量化至关重要-marchnative让编译器自动识别当前 CPU 支持的指令集自动启用 AVX2 或 AVX-512-fopenmp启用 OpenMP 并行否则默认单线程测的是峰值带宽的 1/N-DSTREAM_ARRAY_SIZE200000000定义数组长度为 2 亿个 float 元素 → 占用内存 2e8 × 4B 800 MB远大于典型 L3 缓存如 64MB确保强制走 DRAM-DNTIMES10每个测试项重复 10 次取后 5 次平均值前 5 次用于预热缓存与 TLB-DSTREAM_TYPEfloat使用 float 类型比 double 更友好减少数据搬运量更易打满带宽。编译成功后执行./stream_omp_float你会看到类似输出------------------------------------------------------------- STREAM version $Revision: 5.10 $ ------------------------------------------------------------- This system uses 8 bytes per array element. Array size 200000000 (elements), Offset 0 (elements) Memory per array 1525.879 (MiB) ≈ 1.5 GB Total memory required 4577.637 (MiB) ≈ 4.5 GB Each kernel will be executed 10 times. The *best* time for each kernel (excluding the first iteration) will be used to compute the reported bandwidth. ------------------------------------------------------------- Number of Threads requested 8 Number of Threads counted 8 ------------------------------------------------------------- Your clock granularity/precision appears to be 1 microseconds. Each test below will take on the order of 1000000 microseconds (1 sec). ( 1000000 iterations) ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 124521.3 0.012880 0.012850 0.012920 Scale: 123890.1 0.012930 0.012900 0.012970 Add: 131255.7 0.019320 0.019280 0.019370 Triad: 130722.4 0.019400 0.019350 0.019450 ------------------------------------------------------------- Peak memory bandwidth (based on total copy scale add triad): 130122.4 MB/s -------------------------------------------------------------注意看Number of Threads counted 8—— 这表示 OpenMP 成功识别了全部 8 个逻辑核。若显示1说明-fopenmp未生效或环境变量OMP_NUM_THREADS被设为 1。2.2 四核绑定实测用 taskset 锁定物理核心排除超线程干扰多核共享内存控制器但超线程SMT线程共用同一套执行单元和内存请求队列。若用全部逻辑核如 32 线程跑stream可能因资源争抢导致带宽反而下降。最佳实践是绑定到物理核心而非逻辑线程尤其在双路系统中需明确跨 NUMA 节点行为。假设你的 CPU 是 8 核 16 线程Intel i9-13900K 或 AMD Ryzen 7 7800X3D物理核心编号为0,2,4,6跳过超线程对执行# 绑定到核心 0,2,4,6共 4 个物理核 taskset -c 0,2,4,6 ./stream_omp_float此时输出中Number of Threads counted应为4且Best Rate MB/s值往往比全核运行更高尤其在 DDR4 平台。这是因为减少了内存请求仲裁开销提升了 IMC 利用率。为什么不用 numactlnumactl --cpunodebind0 --membind0 ./stream_omp_float看似更规范但它绑定的是 NUMA 节点而非具体核心。在单路系统中效果等同taskset但在双路系统中若未显式指定--membindOpenMP 可能跨节点分配内存页导致非一致性访问NUMA penalty测出的反而是“伪带宽”。taskset更底层、更可控是定位硬件瓶颈的第一步。2.3 验证数组是否真正绕过缓存用 perf 监控 LLC-missesstream的设计哲学是“强制走内存”但若STREAM_ARRAY_SIZE设得太小如1e6整个数组可能被 L3 缓存容纳测的其实是缓存带宽毫无意义。我们用perf工具验证是否真实触发 DRAM 访问# 在运行 stream 前启动 perf 监控 LLCLast Level Cache缺失率 perf stat -e cycles,instructions,cache-references,cache-misses,LLC-loads,LLC-load-misses \ -x, ./stream_omp_float 21 | grep -E (LLC|cache|rate)理想输出应包含LLC-loads,1234567890 LLC-load-misses,1220000000 LLC-load-misses rate: 98.9%判断标准LLC-load-misses rate 95%才算合格。若只有70%说明约 30% 数据命中 L3数组太小需增大STREAM_ARRAY_SIZE如翻倍至400000000重新编译再测。这是很多初学者翻车的第一坑——以为跑出了高带宽实则测的是缓存。3. 四大测试项背后的访存模式解密Copy/Scale/Add/Triad 到底在考什么3.1 Copy最基础的“读-写”流水线暴露内存控制器读写平衡能力Copy测试执行操作a[i] b[i]→ 1 次读b 数组 1 次写a 数组 每元素 2 次内存事务→ 理论带宽 2 × STREAM_ARRAY_SIZE × sizeof(float) / min_time这是最“干净”的测试无数据依赖、无计算、纯搬移。它直接反映内存控制器的读写通道利用率。若Copy带宽显著低于其他项如低 15% 以上常见原因有主板 BIOS 中 “Memory Write Acceleration”MWA被禁用DDR 颗粒质量不均某条内存条写入时序不稳定使用了 ECC 内存且未开启 “ECC Scrubbing Disable”。玄学经验在部分 AMD EPYC 平台Copy带宽常比Triad低 3–5%这是正常现象——因为 EPYC 的 IMC 对写合并write combining优化更强而Copy无法利用该特性。3.2 Scale引入标量乘法考验 CPU 向量化与内存预取协同Scale执行a[i] q × b[i]其中q是常量如3.0→ 1 次读b、1 次标量乘、1 次写a→ 关键在于乘法是否被编译器向量化是否触发硬件预取器编译时-marchnative至关重要。若 CPU 支持 AVX-512gcc会生成vmulps zmm0, zmm1, zmm2指令一次处理 16 个 float若仅支持 SSE4.2则用mulps xmm0, xmm1一次 4 个。你可以用objdump -d ./stream_omp_float | grep vmulps查看是否生成了 AVX-512 指令。血泪经验某次在 Intel Xeon Platinum 8380 上Scale带宽比Copy低 12%检查发现 BIOS 中 “Hardware Prefetcher” 被关闭。开启后Scale提升 9.3%而Copy几乎不变——证明预取器对含计算的访存模式收益巨大。3.3 Add数据依赖链的起点揭示内存延迟对吞吐的隐性压制Add执行a[i] b[i] c[i]→ 2 次读b,c 1 次加法 1 次写a→ 表面看是“2R1W”但关键在地址局部性b[i]和c[i]是否映射到同一内存通道现代内存控制器将地址哈希到不同通道Channel A/B/C/D。若b和c数组起始地址对齐方式相同如都按 4KB 页对齐它们可能被哈希到同一通道造成单通道拥塞。stream源码中通过OFFSET宏默认 0可错开起始地址// 修改 stream_v5.10.c 中第 122 行附近 #define OFFSET 2000000 // 错开 200 万个 float 元素8MB重新编译后Add带宽常提升 5–8%这就是通道负载均衡的实证。3.4 Triad最贴近真实负载的“读-计算-写”闭环暴露内存控制器调度瓶颈Triad执行a[i] b[i] q × c[i]→ 2 次读b,c 1 次标量乘 1 次加法 1 次写a→ 5 次内存/计算操作但只产生 1 次写回这是四个测试中最“重”的一项也是最接近科学计算中y alpha*x beta*yBLAS axpy的模式。它的带宽往往最高因为① 编译器可将q × c[i]和b[i] ...合并为融合乘加FMA指令若 CPU 支持② 内存控制器对“读多写少”的混合模式调度更高效。注意Triad带宽不应超过Copy的 1.2 倍。若Triad达到Copy的 1.5 倍大概率是数组未真正驻留内存LLC miss rate 90%或编译器做了非法优化如将整个循环提至寄存器。务必用perf复验。4. 避坑stream 测试中 4 个真实踩过的坑与现场排查指南4.1 现象Number of Threads counted 1无论怎么设OMP_NUM_THREADS都无效原因系统缺少 OpenMP 运行时库或gcc编译时未链接libgomp。某些精简版 Linux 发行版如 Alpine默认不带 OpenMP。解决① 检查libgomp.so是否存在find /usr -name libgomp* 2/dev/null② 若不存在安装对应包Ubuntu/Debian 执行sudo apt install libgomp1CentOS/RHEL 执行sudo yum install libgomp③ 重新编译加-lgomp强制链接gcc -O3 -marchnative -fopenmp -lgomp ...。4.2 现象Triad带宽突降 40%Copy正常perf显示LLC-load-misses rate 99.2%原因CPU 温度过高触发 thermal throttling降频导致 FMA 指令吞吐下降但内存控制器频率未降故Copy影响小。解决① 实时监控温度watch -n1 sensors | grep Package② 若 Package temperature 85°C暂停测试清理散热器灰尘或降低环境温度③ 在 BIOS 中关闭 “Intel Turbo Boost” 或 “AMD Precision Boost”锁定基础频率再测确认是否为温控问题。4.3 现象双路服务器上taskset -c 0-7第一颗 CPU测得 120 GB/s但taskset -c 8-15第二颗 CPU仅 75 GB/s原因第二颗 CPU 对应的内存插槽未插满或插了不同规格内存如一条 DDR5-4800一条 DDR5-4400导致整条通道降速至最低规格。解决① 查看内存配置sudo dmidecode -t memory | grep -E (Size|Speed|Bank|Locator)② 确保每颗 CPU 对应的内存通道插槽成对、同品牌、同容量、同频率③ 进 BIOS进入 “Advanced → Memory Configuration”确认 “Memory Frequency” 对两颗 CPU 一致且未出现 “Downclocked” 提示。4.4 现象stream输出中Min time和Max time相差 15%波动剧烈原因系统后台进程干扰如 logrotate、snapd、systemd-journald 刷盘、或 CPU 频率动态调节Intel SpeedStep / AMD CoolnQuiet未关闭。解决① 测试前关闭干扰服务sudo systemctl stop snapd logrotate rsyslog② 锁定 CPU 频率# 查看当前策略 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 切换为 performance 模式需 root echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor # 验证 grep MHz /proc/cpuinfo | head -3③ 重新运行streamMin/Max time差值应 3%。5. 进阶技巧用 stream 定位 NUMA 不平衡与内存通道故障的三步法5.1 第一步分离测试——单 NUMA 节点内各通道独立打点双路服务器通常有 2 个 NUMA 节点Node 0 和 Node 1每节点连接 2–4 条内存通道。要定位是“跨节点慢”还是“某通道坏”必须拆开测。以 2 路 Intel Xeon 634828 核/56 线程每路 4 通道为例# 测 Node 0 的通道 AB核心 0-13 numactl --cpunodebind0 --membind0 taskset -c 0-13 ./stream_omp_float # 测 Node 0 的通道 CD核心 14-27 numactl --cpunodebind0 --membind0 taskset -c 14-27 ./stream_omp_float # 测 Node 1 的全部通道核心 28-55 numactl --cpunodebind1 --membind1 taskset -c 28-55 ./stream_omp_float记录四组Triad带宽。若 Node 0 的 AB 通道为 115 GB/sCD 通道仅 62 GB/s则高度怀疑 C 或 D 通道内存条故障或插槽接触不良。5.2 第二步交叉验证——强制跨节点分配内存复现 NUMA penalty若怀疑跨节点访问慢需人为制造跨节点内存分配# 在 Node 0 上运行但内存分配在 Node 1 numactl --cpunodebind0 --membind1 taskset -c 0-7 ./stream_omp_float此时Triad带宽若跌至 40–50 GB/s降幅 50%说明① NUMA balancing 未生效/proc/sys/kernel/numa_balancing 0② 或 BIOS 中 “Node Interleaving” 被开启应关闭让 OS 管理 NUMA③ 或应用程序未做numactl --membind绑定导致 page fault 时随机分配到远端节点。5.3 第三步故障隔离——用 memtest86 与 stream 结合做通道级诊断stream能暴露带宽异常但不能定位硬件故障。当某通道持续偏低如稳定在 30 GB/s需进一步验证步骤操作目的1. 物理拔插关机拔下疑似故障通道的内存条如 Node 0 的 Channel C仅保留 ABD 三条排除接触不良若带宽恢复说明该条故障2. 替换测试将该内存条换到另一台同型号服务器的 Channel A 插槽确认是否内存条本体损坏非主板插槽问题3. Memtest86 全盘扫描制作 U 盘启动盘运行memtest86 v6.20选择 “Test All” 模式至少跑 4 轮检测内存颗粒坏块、ECC 纠错失败、地址线短路等底层故障我的习惯每次交付新服务器我必做三件事——① 用stream跑满所有通道记录基线值② 用ipmitool sdr type memory检查 DIMM 温度与电压是否在规格内③ 用dmidecode -t memory导出内存拓扑图标注每条内存的 Slot、Size、Speed、Manufacturer存档备查。这些动作耗时不到 20 分钟但能在未来半年避免 80% 的“性能忽高忽低”类客诉。希望帮到你。本文还有配套的精品资源点击获取