如何测试美国服务器E5、Xeon Gold/Platinum与EPYC平台的多核吞吐？

多核吞吐测试不能只看 CPU 型号、核心数量或某一次跑分。E5、Xeon Gold/Platinum 与 EPYC 可能在单线程响应、全核吞吐、内存带宽、NUMA 访问和虚拟化稳定性上呈现不同取向。较可靠的做法，是把测试拆成单线程、固定并发、物理核心满载、逻辑线程满载和真实业务负载几个层次，再同时记录吞吐、延迟、CPU 利用率、内存带宽与 I/O 等数据。

美国服务器的地域主要影响网络往返和跨区域业务延迟，不应直接混入 CPU 性能结论。测试本地计算、压缩、编译或数据库处理能力时，应尽量在服务器本机完成；测试 Web、API 或跨地域服务时，则要单独记录美国机房到请求端的网络 RTT、丢包、带宽和连接复用情况。最终比较的不是“哪一类 CPU 一定更快”，而是在相同软件、并发、内存和磁盘条件下，哪种平台能以可接受的尾延迟稳定完成目标工作量。

测试目标：把“多核性能”拆成可验证的问题

一套有价值的评测至少要回答以下问题：

1. 单线程响应是否足够快：适用于请求链路中存在串行阶段、脚本执行、事务处理和低并发 API 的场景。
2. 多线程吞吐能否随着并发增长：适用于批量计算、转码、编译、压缩、日志处理和并行任务。
3. 内存是否成为瓶颈：适用于缓存、数据库、科学计算和大规模数据扫描。
4. NUMA 和双路拓扑是否影响扩展性：适用于双路 E5、双路 Xeon 或双路 EPYC 服务器。
5. 磁盘与网络是否掩盖了 CPU 差异：适用于数据库、Web 服务和高并发文件处理。
6. 在目标延迟下可承载多少并发：适用于容量规划，而不是只追求最高 QPS。

测试对象必须精确到平台配置

“E5”“Xeon Gold”“Xeon Platinum”和“EPYC”都不是单一型号。不同代际、主频、核心数、缓存、内存通道和功耗限制，可能让同一系列内部出现明显差异。

至少记录以下硬件信息：

例如，单路 32 核 EPYC 与双路 16 核 Xeon Gold 不能只按“32 核对 32 核”比较。前者可能拥有更完整的本地内存资源，后者可能存在跨插槽访问；如果内存条数量和通道填充方式不同，CPU 型号本身就不是唯一变量。

筛选美国服务器测试样本时，可以先用具体套餐建立配置对照。A5数据的美国AMD系列中，EPYC 4584PX搭配64GB DDR5和960GB NVMe，EPYC 7713搭配128GB内存和两块1.92TB NVMe。这两档可作为不同工作集规模的候选配置，但不能直接将整机吞吐差异归因于CPU；比较时需固定输入规模，并分别记录内存与存储差异，避免把容量优势误判为多核扩展优势。

指标含义：吞吐、延迟和利用率必须同时观察

吞吐量

吞吐量表示单位时间完成的工作量，常见单位包括：

• jobs/s：每秒完成的任务数；
• requests/s 或 QPS：每秒处理的请求数；
• records/s：每秒处理的数据记录数；
• MB/s、GB/s：每秒处理的数据量；
• builds/min：单位时间完成的构建任务数。

不要把不同工作量的结果直接相加。例如，一个压缩任务处理 1 GB 数据，另一个任务只处理 100 MB，即使两者都显示为一次完成，也不能直接用“任务数”比较。更合理的做法是固定输入数据量，并同时记录任务耗时和单位时间处理量。

延迟和尾延迟

平均延迟适合观察整体趋势，但不适合作为高并发服务的唯一指标。至少记录：

• P50：中位数，代表典型请求；
• P95：95% 请求不超过的延迟；
• P99：尾部请求延迟；
• 最大值或超时率：观察极端抖动。

当并发提高后，QPS 仍在增加但 P99 快速上升，通常说明系统接近饱和。此时继续加线程，得到的可能只是更高的排队时间，而不是更有用的服务能力。

CPU 利用率与每核状态

总 CPU 利用率不足以解释问题。多线程程序可能只使用了部分核心，也可能被单个线程限制。需要同时观察：

• 用户态 CPU：业务计算消耗；
• 内核态 CPU：系统调用、网络、I/O 和调度开销；
• iowait：等待存储或其他 I/O；
• 每个逻辑 CPU 的利用率；
• 实际频率是否在长时间负载下下降；
• 上下文切换和运行队列长度。

一个测试显示总 CPU 利用率 45%，并不代表还有一半性能可以直接使用。如果其中一个核心长期 100%，其他核心空闲，瓶颈可能是串行代码、锁竞争或单线程事件循环。

内存带宽与容量

多核任务不断从内存读取数据时，CPU 核心数增加不一定带来相同比例的吞吐。可记录：

• 总内存带宽；
• 读写带宽；
• NUMA 本地访问和远端访问；
• 内存使用量与回收活动；
• 缓存命中率；
• Swap 或内存压缩情况。

内存容量主要决定是否能容纳工作集，内存带宽则决定数据能否及时供给核心。一个任务即使只使用 50% 内存容量，也可能已经耗尽可用带宽。

I/O 指标

存储测试应至少记录：

• 顺序读写带宽；
• 随机读写 IOPS；
• 平均延迟；
• P95/P99 I/O 延迟；
• 队列深度；
• CPU 使用率和 iowait。

I/O 吞吐的单位必须统一。十进制口径下，1 GB 等于 1,000,000,000 字节；如果 60 秒写入 1 GB，换算为比特率是：

1,000,000,000 × 8 ÷ 60 = 133,333,333 bit/s，约为 133.3 Mbps。

硬盘工具显示的 GiB、MiB 与网络工具显示的 Gb、Mb 不能直接混用。

影响结果的关键变量

E5、Xeon Gold/Platinum 与 EPYC 的测试取向

下面是测试设计上的典型关注点，不是对所有型号的固定结论：

E5 还需要进一步区分 v3、v4 等代际；Gold 和 Platinum 也应记录完整型号，不能只写系列名称。EPYC 同样存在多代架构和不同核心数的产品，单路与双路的内存访问方式也不相同。

SMT、睿频和功耗策略

同时多线程，也就是 SMT 或超线程，会增加可调度线程数，但不会等比例增加物理执行资源。测试应至少保留三种模式：

1. 1 个线程，观察单线程延迟；
2. 物理核心数线程，观察真实核心的吞吐；
3. 逻辑线程数线程，观察 SMT 带来的额外收益。

长时间负载下，短时间内的睿频成绩可能下降。建议设置预热阶段，并把正式测量延长到 60 秒或更长。若业务是持续批处理，还应增加 10 至 30 分钟的稳定性测试，记录频率、温度和功耗趋势。

NUMA 与内存通道

双路服务器、部分多芯粒设计的 EPYC，以及大型 Xeon 平台，都可能受到 NUMA 影响。线程在一个节点运行、数据却位于另一个节点时，延迟和带宽都会发生变化。

需要记录：

• NUMA 节点数量；
• 每个节点的 CPU 核心；
• 每个节点的内存容量；
• 内存条是否均匀插入各通道；
• 测试线程和内存是否绑定在同一节点。

如果业务框架支持 NUMA 绑定，可以分别测试本地内存和跨节点访问；如果业务不支持，则应使用默认调度方式，模拟真实部署状态，不要只报告经过精细绑定后的理想结果。

虚拟化与邻居干扰

美国服务器可能是裸金属，也可能是 VPS、独享 vCPU 或共享 vCPU。虚拟机中需要核对：

• vCPU 是否对应独占物理核心；
• 是否能看到完整 NUMA 拓扑；
• CPU steal time 是否长期升高；
• 内存是否超售；
• 磁盘是否为共享存储；
• 测试期间是否有其他实例争用。

同一型号 CPU 在裸金属和共享虚拟化环境中的结果，不应放在同一排名中。虚拟机出现吞吐周期性下降、P99 抖动或 steal 升高时，应优先排查宿主机调度，而不是直接归因于 CPU 架构。

测试准备：固定环境后再运行基准

采集硬件与系统信息

Linux 环境可以先执行以下命令。命令用于读取信息，不会修改系统配置：

uname -a
lscpu
numactl -H
free -h
lsblk -o NAME,SIZE,ROTA,TYPE,FSTYPE,MOUNTPOINTS
systemd-detect-virt
cat /sys/devices/system/cpu/smt/active

若使用 numactl、lscpu 或 systemd-detect-virt 时提示命令不存在，应先确认发行版和工具包，不要根据未知环境直接套用安装命令。还可以记录测试时的频率和负载：

mpstat -P ALL 1 10
pidstat -u -r -d 1 10

如果权限允许，可补充处理器计数器数据：

perf stat -e cycles,instructions,cache-misses,context-switches \
  --timeout 60000 \
  <待测程序及参数>

perf 可能受到内核权限策略限制，无法采集时应记录限制原因，不要把缺失的数据填成估算值。

统一测试条件

两台美国服务器进行对比时，至少固定以下条件：

• 相同操作系统大版本和内核类型；
• 相同编译器、运行时和应用版本；
• 相同数据集、压缩级别和线程参数；
• 相同预热时间、测试时长和重复次数；
• 相同磁盘测试路径与文件系统；
• 相同 CPU 线程绑定策略；
• 相同请求生成端和网络路径；
• 测试期间没有系统升级、备份或批量任务。

每组测试建议执行一次预热，再进行 5 次正式采样。对耗时、吞吐和延迟结果，可取中位数作为主值，并报告最大波动范围。对于 P95、P99，不应把每次测试的百分位数简单平均后当作整体尾延迟；更严谨的方式是保存每次请求的延迟样本，合并后重新计算百分位数。

推荐的线程矩阵

线程数不要只选择“1”和“最大值”。一组较有解释力的矩阵可以是：

对于双路服务器，还可以增加“单 NUMA 节点”和“全 NUMA 节点”两组，以识别跨节点扩展损失。

测试项目：从合成基准走向业务负载

CPU 整数与多线程吞吐

sysbench cpu 可以用于建立基础对照。下面是示例命令，具体参数要依据实际安装版本确认：

sysbench cpu \
  --cpu-max-prime=20000 \
  --threads=1 \
  --time=60 \
  run

sysbench cpu \
  --cpu-max-prime=20000 \
  --threads=32 \
  --time=60 \
  run

测试时应将 --threads 替换为线程矩阵中的多个值。该类测试适合观察整数运算和线程扩展，不代表数据库、压缩或 Web 服务的全部表现。

可以使用以下指标衡量扩展效率：

• 加速比 = 多线程吞吐 ÷ 单线程吞吐；
• 并行效率 = 加速比 ÷ 线程数；
• 单核吞吐 = 总吞吐 ÷ 实际参与的物理核心数。

例如，单线程完成 100 个任务/秒，32 线程完成 2,400 个任务/秒，则加速比为 24 倍，并行效率为 24 ÷ 32 = 75%。如果另一平台单线程为 120 个任务/秒、32 线程为 2,200 个任务/秒，它的串行能力更强，但全核总吞吐反而可能较低。两者应根据业务是低并发还是批量并行来选择。

内存带宽

内存测试至少要覆盖单线程和多线程。sysbench memory 可用于快速比较，但它属于合成负载：

sysbench memory \
  --memory-block-size=1M \
  --memory-total-size=100G \
  --memory-oper=read \
  --threads=1 \
  run

sysbench memory \
  --memory-block-size=1M \
  --memory-total-size=100G \
  --memory-oper=read \
  --threads=32 \
  run

如果数据集过小，可能主要命中 CPU 缓存；如果数据集太大且触发交换，又会混入磁盘影响。测试数据应明显大于末级缓存，同时小于可用内存，避免 Swap。写入测试要注意内存页、缓存策略和工具版本差异，结果应只用于同环境横向比较。

内存带宽随线程增加后很快趋于平台上限，通常意味着任务已从“算力受限”转为“内存受限”。此时增加更多核心不会带来同比例收益，应该优先比较内存通道、频率、NUMA 布局和访问局部性。

编译、压缩和批处理

真实业务负载比合成基准更接近采购目标。可选择固定源码树、固定压缩文件或固定数据集，记录：

• 总耗时；
• 每秒处理量；
• CPU 用户态占比；
• 内存峰值；
• 是否出现 I/O 等待；
• 线程数增加后的收益。

例如，编译任务可以设置 make -j1、make -j物理核心数 和 make -j逻辑线程数，但要固定编译器、链接器、依赖缓存状态和存储位置。首次编译与增量编译不能放在同一组结果中，因为增量编译可能受到文件系统缓存影响。

压缩任务要固定算法、压缩等级和输入文件。高压缩等级可能更依赖 CPU，低压缩等级可能更依赖内存和磁盘。若结果需要用于日志归档，应使用与生产相同的压缩格式，而不是只使用一个与业务无关的算法。

Web 或 API 并发

Web 服务测试时，请求生成端应独立于被测服务器，避免本机客户端占用 CPU。应固定：

• 请求内容与响应大小；
• Keep-Alive 和连接复用；
• TLS 是否启用；
• 数据库是否参与；
• 静态文件缓存状态；
• 并发连接数和持续时间；
• 请求生成端到美国机房的网络路径。

测试结果至少包含请求速率、P50/P95/P99、错误率和服务器端 CPU 利用率。可以设置并发 1、8、32、128 等多个梯度，寻找延迟开始陡增的位置。若只报告最高 QPS，容易把排队和超时误认为性能提升。

对于跨地域 API，应把“服务器本机处理耗时”和“客户端看到的总耗时”分开。总耗时可以近似拆分为：

网络往返时间 + TLS/连接开销 + 排队时间 + 应用处理时间 + 响应传输时间

美国服务器所在城市、请求端位置和运营商路由变化，都可能改变第一项和最后一项。它们不能直接用来证明某种 CPU 更快。

存储与混合负载

I/O 测试只能在专用测试卷或明确的测试文件上进行。不要把生产数据库文件、系统盘或客户数据路径直接交给写入型基准工具。测试前应确认数据备份、影响范围和可回滚方式；测试结束后只清理已经确认属于测试范围的文件。

下面是一个使用测试文件的示例，路径需替换为专用挂载点：

fio \
  --name=randread_cpu_observe \
  --filename=/mnt/benchmark/testfile \
  --size=8G \
  --rw=randread \
  --bs=4k \
  --ioengine=libaio \
  --iodepth=32 \
  --numjobs=4 \
  --direct=1 \
  --time_based \
  --runtime=60 \
  --group_reporting

该命令会对指定测试文件产生实际读取压力；如果改为写入或混合读写，必须确认目标卷不是生产数据盘，并提前制定停止和恢复方案。测试期间同时观察 CPU 使用率和 iowait：

iostat -x 1 60
pidstat -d -u 1 60

如果 CPU 利用率只有 30%，但磁盘队列和 I/O 延迟已达到平台上限，继续更换更高核心数的 CPU 可能无法改善结果。相反，如果磁盘延迟稳定、CPU 长时间满载，才有必要继续比较 CPU 核心规模和线程扩展。

结果解释：不要用一个分数替代性能画像

用扩展曲线识别瓶颈

把线程数作为横轴，把吞吐量和 P99 延迟作为纵轴，通常比单一总分更有价值。典型曲线可能出现以下形态：

• 吞吐近似线性增长，P99 变化较小：任务仍处于可扩展区；
• 吞吐增长变慢，内存带宽接近上限：内存受限；
• 吞吐基本不变，CPU 某一核心满载：串行代码或锁竞争；
• 吞吐继续上升，但 P99 快速增加：进入排队区；
• 总 CPU 不高且 iowait 上升：I/O 受限；
• 结果随时间周期性下降，steal 或频率变化：虚拟化或功耗策略影响。

可以使用一组归一化示例帮助理解。以下数字仅用于说明分析方法，不代表某个美国机房或具体型号的实测结果：

样本 B 的单线程表现更好，样本 C 的总吞吐更高。若业务是在线接口，可能更关注 B 的 P95/P99；若业务是夜间批处理，C 的总吞吐和单位时间处理量可能更有价值。不能仅凭最后一列或核心数下结论。

识别 CPU 受限、内存受限和 I/O 受限

可以按照以下方式交叉判断：

注意跨 NUMA 的性能损失

如果单节点测试的吞吐为 1,000，双节点全开后达到 1,750，扩展效率是 1,750 ÷ 2,000 = 87.5%。若只有 1,250，扩展效率为 62.5%，则需要检查：

• 线程是否均匀分布；
• 数据是否被错误地集中在一个节点；
• 内存通道是否完整填充；
• 应用是否频繁访问远端内存；
• 双路平台是否存在跨插槽锁竞争。

对于不能感知 NUMA 的程序，双路服务器未必能把理论核心数全部转化为有效吞吐。对于具备良好线程和内存分区能力的批处理程序，双路或高核心 EPYC 才更可能体现规模优势。

把结果转成选择依据

低并发和延迟敏感业务

如果业务主要是管理后台、轻量 API、单线程脚本、事务处理或小型数据库，应优先关注：

• 单线程吞吐；
• P95/P99 延迟；
• 低并发下的 CPU 频率；
• 内存延迟和缓存命中；
• 存储随机 I/O；
• 高峰时的排队时间。

这类场景不应只为获得更多核心而购买高核心数平台。老款 E5 如果单线程和存储延迟已经成为瓶颈，即使有足够的线程数，也无法改善串行请求的响应。

多线程批处理和高并发计算

编译、转码、压缩、日志分析和并行计算应关注：

• 物理核心满载吞吐；
• 全逻辑线程额外收益；
• 长时间频率稳定性；
• 内存带宽；
• 任务调度和 NUMA 扩展；
• 每完成一个任务消耗的时间和资源。

EPYC 或高核心数 Xeon 平台通常更值得进入这类测试，但前提是软件确实能把工作拆分到多个线程，并且许可证、调度器和内存布局不会抵消核心数量优势。若全逻辑线程只比物理核心提高少量吞吐，却显著增加 P99，就不应把 SMT 全开作为生产默认配置。

虚拟化、数据库和综合服务

这类负载不能只用 CPU 基准做决策。应把 CPU、内存、存储和网络组合起来：

• 数据库测试固定数据规模、索引和缓存状态；
• Web 测试固定响应大小、连接方式和后端依赖；
• 虚拟化测试观察 steal、内存超售和磁盘抖动；
• 跨地域服务分离服务器处理时间与美国网络路径；
• 高峰容量以目标 P99 和错误率作为限制，而不是最高 QPS。

成本判断

拿到实际月费或报价后，可以计算：

单位吞吐成本 = 月费用 ÷ 目标负载下的有效吞吐

“有效吞吐”应使用满足延迟和错误率约束的值。例如某平台在 2,000 QPS 时 P99 超过业务上限，那么即使它能达到 2,500 QPS，也只能把 1,800 或 2,000 QPS 以内的合规数据用于成本比较。

还可以补充：

• 每个物理核心的有效吞吐；
• 每 GB 内存的月成本；
• 每个数据库实例的许可成本；
• 存储和带宽的附加费用；
• 预留 20% 至 30% 容量后的实际可用吞吐。

当前报价、库存、带宽套餐和交付周期应以具体美国服务器方案为准，不能用 CPU 型号推断全部成本。

验收与复测边界

用于采购或迁移验收时，建议把测试条件写入记录，而不是只保留一个截图。至少包括：

• 完整 CPU 型号、路数和核心线程数；
• 内存容量、频率和通道布局；
• 磁盘型号、挂载点和文件系统；
• 操作系统、内核、应用和基准工具版本；
• 线程数、绑核方式和 NUMA 策略；
• 测试数据集和输入文件校验值；
• 预热时间、正式时长和重复次数；
• 吞吐、P50、P95、P99、错误率；
• CPU、内存、I/O、频率和 steal 监控数据；
• 测试时间窗口与网络请求端位置。

复测时只改变一个主要变量。例如先保持 CPU 和软件不变，比较单路与双路内存布局；再保持硬件不变，比较物理核心和逻辑线程；最后才比较不同 CPU 平台。若同时更换服务器、磁盘、内核和应用版本，即使结果发生变化，也很难判断具体原因。

用容量曲线确定可用上限

实际部署可以从目标负载反推容量，而不是从理论核心数估算。步骤如下：

1. 取生产中最接近的请求或批处理数据集；
2. 设置低并发并记录基线吞吐和 P99；
3. 逐级增加并发，直到目标 P99、错误率或 CPU 使用率达到限制；
4. 取拐点前的稳定吞吐作为单台有效容量；
5. 按业务峰值、故障冗余和增长空间计算服务器数量；
6. 更换 CPU 或内存平台后，用完全相同的数据集复测。

例如，业务规定 P99 不超过 200 ms、错误率不超过 0.1%，某平台在 1,600 QPS 时满足条件，在 1,900 QPS 时 P99 达到 420 ms，那么容量规划应使用 1,600 QPS 附近的有效值，而不是基准工具报告的峰值。若预留 25% 余量，可按约 1,200 QPS 作为单台计划容量，再结合故障切换和美国机房的网络波动安排实例数量。

这种方法能把 E5、Xeon Gold/Platinum 与 EPYC 的比较从“跑分排名”转为业务可执行的选择：低延迟任务看单核与尾延迟，多线程任务看物理核心扩展和持续吞吐，内存密集任务看带宽与 NUMA，数据库和 Web 服务则必须把 CPU、内存、I/O 与网络路径放在同一张容量曲线上判断。