Hetzner作为欧洲知名的IDC服务商，凭借高性价比的云服务器和独立服务器受到不少开发者的青睐。不过很多人在选型时只看vCPU数量和主频，却忽略了一个关键指标——内存带宽。对于数据库、科学计算、大数据处理这类内存密集型负载来说，内存子系统的吞吐能力往往才是真正的瓶颈。Stream就是目前业界最常用的内存带宽测试工具，本文将详细介绍如何在Hetzner服务器上正确运行Stream测试，并解读实测结果。
Stream测试的原理与编译方法
Stream由弗吉尼亚大学的John McCalpin博士开发，通过四种核心操作来度量内存带宽：Copy（复制）、Scale（乘法缩放）、Add（向量加法）和Triad（复合操作）。其中Triad结合了读取、写入和运算，最接近真实应用中的内存访问模式，因此通常以Triad成绩作为平台内存带宽的代表值。
测试的核心思想很简单：定义远大于CPU缓存容量的数组，强制处理器反复访问主存，从而测出持续带宽而非突发带宽。编译时需要根据CPU核心数调整OpenMP线程数，并保证数组规模足够大。下面是一份可直接使用的编译命令，假设服务器有8个核心，每个线程分配约8000万个双精度元素：
# 安装编译工具 apt update && apt install -y gcc make # 设置线程数与数组规模（NTIMES取20次以降低偶然误差） gcc -O3 -mcmodel=medium -fopenmp -DNTIMES=20 -DSTREAM_ARRAY_SIZE=64000000 -DOPEN stream.c -o stream # 通过环境变量控制并行线程 export OMP_NUM_THREADS=8 export OMP_PROC_BIND=close export OMP_PLACES=cores ./stream
有两个编译细节值得注意。一是必须加上-mcmodel=medium或-mcmodel=large，否则大数组会导致链接失败；二是OMP_PROC_BIND和OMP_PLACES的设置能让线程绑定到固定核心，避免线程迁移带来的抖动，测试结果会更稳定。另外每次测试建议至少跑五轮取中位数，单次结果容易受同宿主机邻居虚拟机的影响。
Hetzner云服务器实测成绩分析
Hetzner的云服务器（CX、CPX、CCX系列）基于AMD EPYC平台，共享宿主机的内存控制器。以CPX41（8 vCPU，EPYC 7003系列）为例，实测Triad成绩通常在40到55 GB/s之间浮动，波动幅度比独立服务器明显更大，这正是共享基础架构的特征——带宽配额会随邻居负载变化。CCX系列是独享vCPU型号，实测表现更稳定，CCX23（4 vCPU）的Triad成绩约在30到40 GB/s，且方差小得多。
p>下面是一次典型的输出结果，供参考：------------------------------------------------------------- This system uses 8 bytes per array element ------------------------------------------------------------- Function Rate (MB/s) Copy: 43210.7 Scale: 41002.3 Add: 46875.9 Triad: 45230.1 ------------------------------------------------------------- Solution Validate: Pass
对比来看，物理EPYC服务器（如独立服务器AX系列）的8通道DDR4-3200理论带宽约204.8 GB/s，Stream实测一般能达到理论值的70%到85%。而云实例的得分明显低于物理机，一方面是vCPU数量限制了可用内存通道的并发度，另一方面Hypervisor对内存带宽做了限额管理，防止单个租户抢占过多资源。如果你的应用是纯带宽瓶颈型，这个差距在采购决策时必须纳入考量。
影响测试结果的关键因素与避坑指南
第一个常见坑是数组规模设得太小。如果STREAM_ARRAY_SIZE对应的数组总大小没有超过CPU三级缓存的四倍以上，测试测到的其实是缓存带宽而非内存带宽，数字会虚高一倍以上。CPX系列的三级缓存可达256MB，因此数组规模建议不小于1GB对应的元素数。
第二个因素是NUMA结构。EPYC是多NUMA节点设计，如果线程和数据分散在不同NUMA节点上，跨节点访问会显著拉低带宽。可以用numactl --hardware查看节点拓扑，再用numactl -l ./stream绑定本地内存执行。第三个因素是超线程，跑Stream时建议只使用物理核心数，开启超线程并不会提升带宽，反而可能因为调度争用降低成绩。
最后要提醒的是，Stream成绩只是理论参考，不能直接等同于业务性能。数据库类应用更看重随机访问延迟，Stream的顺序访问模式对此并不敏感。建议把Stream、sysbench memory和mlc（Intel Memory Latency Checker）组合使用，分别覆盖带宽、吞吐和延迟三个维度，得到的画像才完整。在Hetzner上做这类测试时，选择网络空闲时段、多次取样、记录CPU型号和宿主机负载，都是让数据可信的必要条件。
HetznerStream内存带宽服务器性能测试修改时间：2026-09-07 13:12:30