CPU 与数据库基准 —— SPEC CPU、TPC-C、SPECjbb

第九章第二篇专题讲 CPU 和数据库基准——这是服务器采购合同里最常出现的两组数字。

SPEC CPU2017 ——CPU 性能的事实标尺

SPEC CPU 2017 2017 年发布，取代 2006 版。今天数据中心 CPU datasheet 几乎都用它。

四个子套件

graph TB
  ROOT[SPEC CPU 2017]
  ROOT --> SR[SPECrate
多任务并行
测吞吐]
  ROOT --> SS[SPECspeed
单任务
测响应时间]
  SR --> SRINT[SPECrate Integer
10 个整数程序]
  SR --> SRFP[SPECrate Floating Point
13 个浮点程序]
  SS --> SSINT[SPECspeed Integer
10 个整数程序]
  SS --> SSFP[SPECspeed Floating Point
10 个浮点程序]

实际报告里看到的几个常用名字：

SPECrate2017_int_base / _peak    多核整数吞吐
SPECrate2017_fp_base  / _peak    多核浮点吞吐
SPECspeed2017_int_base/peak      单线程整数响应时间
SPECspeed2017_fp_base /peak      单线程浮点响应时间

base 用规定编译选项（公平比较），peak 允许厂家激进优化（看上限）。真实采购看 base。

怎么读 SPECrate

某 2-socket 服务器 SPECrate2017_int_base = 800
代表：在 2 socket × 64 core × 2 SMT = 256 线程上
      跑 10 个整数 workload 的几何平均吞吐 = 基准的 800 倍

→ 比对 base 越高越快
→ 单核数字 = 800 ÷ 256 ≈ 3.1（"线程效率"参考）

注意：单核高 ≠ 总吞吐高，反之亦然。Intel Xeon SP / AMD EPYC / Ampere AmpereOne 等都有自己 sweet spot——选型时分清自己的 workload 是 throughput-bound 还是 latency-bound。

SPEC CPU 看哪几列

读 SPEC CPU 报告（每条 SUT 一份 PDF + HTML）时关键列：

列	含义	看什么
Hardware	CPU、内存、存储、BIOS	配置基线
Software	OS、编译器、libc、glibc	软件栈
Tunable	NUMA、Turbo、HT、Power Profile	调优
Result	base / peak	实际数字
Energy	部分报告有功耗	能效

比较时一定保证：编译器版本、HT 开关、Power Profile 一致——否则结果不可比。

国内查 CPU 性能时的常见情况

1. 国产 CPU 厂家通常给 SPEC CPU 2006（旧版）数字
   → 不能直接和 Intel/AMD 的 2017 数字比
   → 需要换算（一般 2006 → 2017 大致 0.5-0.6× 缩放，参考意义）

2. ARM Server CPU（鲲鹏 920、AmpereOne）
   → 编译器要支持 SVE/NEON，不然性能掉一半

3. RISC-V Server CPU（少量）
   → 公开 SPEC CPU 数字仍稀缺

待补充：鲲鹏 920 / 海光 / AmpereOne 在 SPEC CPU2017 base 公开数字。

SPECpower：能效

SPECpower_ssj2008 测的是”性能 / 瓦”——服务器能效之标尺。

ssj_ops（操作/秒）/ Watt
从 100% 负载逐档降到 0%（idle）
用 PTDaemon 同步采集功率
最终一个综合分数：overall ssj_ops/W

数据中心选型 TCO 模型几乎都引用 SPECpower 数字——电费占数据中心 OPEX 30-40%，能效高 10% 一年省几百万电费。

SPECjbb 2015：Java 中间件

jbb 全称 Java Business Benchmark。模拟 ERP / 中间件场景：

1
2
3

multi-JVM、多线程、java heap 几十 GB
随机请求、模拟订单/库存/客户
指标：max-jOPS（最大吞吐）/ critical-jOPS（带 SLA 约束的吞吐）

SPECjbb 2015 是 OLAP-like Java 服务器选型主流尺——金融、电信、政府常用。新版还在持续维护，比退役的 SPEC Web2005 时效性强。

TPC-C —— OLTP 经典

TPC 系列里最经典：模拟电商订单系统。

仓库（Warehouse）数 W
订单生成（New-Order）每分钟数 = tpmC
要求 90% 事务在 5s 内完成、ACID 一致性
价格披露 → $ / tpmC

20 世纪 90 年代，TPC（事务处理性能委员会）成立，Benchmark（基准测试）随之走上历史舞台。tpmC 值在国内外被广泛用于衡量计算机系统的事务处理能力，为”每分钟内系统处理新订单个数”的英文缩写。TPMC 测试及发布的成本极高（百万美元级），只有少数厂商的少数设备会在 TPC 官网上发布测试数据。未在官网上发布的数据都是评估出来的。

历史里程碑

1
2
3

2010 IBM Power 780：           10 M tpmC
2013 Oracle SuperCluster：     30 M tpmC
2017+ Oracle Exadata：         50-100 M tpmC（云超大配置）

tpmC 在 2026 年的位置

正式 TPC-C 提交几乎已停滞——发布门槛太高、云时代少有厂家愿意花钱跑。国内合同里”要求 X 万 tpmC”基本是评估值，不是 TPC 官网真实发布。

评估方法：
  根据 SPEC CPU 数字 + 内存 / 存储配置
  按经验公式估算 tpmC
  → 数字接近 TPC-C 官网早年的同档系统

国采、国企招标里仍把 tpmC 作”硬指标”，但实际意义不如 HammerDB 真跑一遍。

HammerDB / sysbench —— 现代 OLTP 测试事实标准

正式 TPC-C 太贵 → 业界用开源工具跑”TPC-C-like” workload：

graph LR
  HDB[HammerDB
开源, GUI/CLI]
  SB[sysbench
开源, CLI]
  HDB --> ORACLE[Oracle / MySQL / PG / MS SQL / Db2]
  SB --> MYSQL[MySQL / PostgreSQL / TiDB]

HammerDB 实现了 TPROC-C（TPC-C 风格）和 TPROC-H（TPC-H 风格），跑出来的指标叫 NOPM（new orders per minute），和 tpmC 同含义但不发布到 TPC 官网。

实操要点

仓库数（warehouse）：       至少 100，实测最好 500-2000（避免被单仓库锁住）
虚拟用户数（vuser）：       从 1 ramp 到 max，看曲线
预热时间：                  5-10 min
持续时间：                  至少 10-20 min
观察指标：                  NOPM, TPM, P99 延迟

典型对比：
  Intel Xeon 8480C 2-socket + 1.5TB RAM + NVMe + Oracle 19c
    → HammerDB NOPM ≈ 8-12 M
  AMD EPYC 9654 2-socket 同配置
    → NOPM ≈ 10-15 M
  鲲鹏 920 2-socket + openGauss
    → NOPM ≈ 4-7 M

待补充：上面数字仅作量级参考，具体看实际配置和调优。

TPC-H / TPC-DS —— 数据仓库 / 大数据

1
2
3

TPC-H：     22 个复杂分析查询，scale factor 1GB-100TB
TPC-DS：    99 个查询，更接近真实数仓 / BI workload
指标：      QphH@SF（每小时查询数 × scale factor）

云时代 TPC-DS 比 TPC-H 更主流——特别是 数据湖 / Spark / Presto / Trino / ClickHouse 都用 TPC-DS 自我对标。

选型场景

单机数据库（Oracle/Db2/MySQL/PG）：HammerDB TPROC-H
分布式数仓（GreenPlum/TiDB/StarRocks/Doris）：TPC-DS @SF1000-10000
云数仓（Snowflake/BigQuery/Redshift）：TPC-DS 公开 benchmarks
湖仓（Iceberg/Hudi/Delta + Trino/Spark）：TPC-DS 是"事实公约数"

数据库基准的真相 —— “选型不能只看 benchmark”

数据库性能受实际数据分布影响巨大：

benchmark：    数据均匀生成、查询模板固定、并发可控
生产：         数据极度不均、热点 key、查询千差万别、并发峰谷波动
              → benchmark 跑得好，生产可能跑不动
              → benchmark 跑得一般，生产可能反而合适

成熟做法：

1. 先跑标准 benchmark 排除明显短板
2. 用真实业务数据做"冒烟测试"（部分库 dump）
3. 用真实查询日志重放
4. 再做 POC（4-8 周生产试运行）

没有 POC 就不敢决定数据库选型——这是 DBA 圈的共识。

CPU + 数据库选型时的几条经验

1. SPECrate2017_int_base 反映"多核吞吐"
   → 数据库 / 中间件场景看它最直接
   
2. SPECspeed 反映"单线程响应"
   → CPU-bound 单线程 task（数据库 query 优化器、序列化）看它

3. SPECpower 反映"性能/瓦"
   → 算 TCO 时核心，3 年电费可能比硬件贵

4. SPECjbb 反映"Java 中间件"
   → Java 应用服务器（WebSphere/JBoss/Tomcat）选型直接对应

5. tpmC 在国内合同里仍存在但实际意义有限
   → 真要测 OLTP，HammerDB 是事实标准

6. CPU 频率 ≠ 性能
   → 看微架构代次（Intel 5/6 代、AMD Zen4/5、ARMv9）+ 内存通道 + AVX/SVE 支持

7. NUMA 拓扑必影响数据库性能
   → 单 socket > 双 socket（少量 workload，看场景）
   → 可以用 numactl 绑核做对照测试

一些命令

# Linux 看 CPU
lscpu                           # 拓扑 / 频率 / NUMA / flag
cat /proc/cpuinfo | head -50    # 详细
numactl --hardware              # NUMA 详情

# 单核基准（速测）
sysbench cpu --threads=1 --cpu-max-prime=20000 run

# 多核基准
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run

# 内存带宽
sysbench memory --memory-block-size=1M --memory-total-size=10G run
mbw 1024                        # 简易内存带宽

# OLTP 快速测试（MySQL）
sysbench oltp_read_write --tables=10 --table-size=1000000 \
  --mysql-host=127.0.0.1 --mysql-user=root \
  --threads=64 --time=120 run

# HammerDB CLI（TPROC-C）
hammerdbcli auto bm-tprocc-pg.tcl    # 全脚本驱动

一张速查

场景	主基准	次要基准
CPU 通用计算	SPEC CPU2017 (rate base)	SPEC CPU2017 (speed base)
CPU 能效	SPECpower	—
单核响应	SPECspeed_int_base	sysbench cpu
Java 中间件	SPECjbb 2015	—
OLTP（MySQL/PG）	sysbench oltp / HammerDB TPROC-C	TPC-C 官网（参考）
OLTP（Oracle/Db2）	HammerDB TPROC-C	TPC-C 官网（参考）
决策支持	TPC-H	HammerDB TPROC-H
大数据数仓	TPC-DS	—

小结

SPEC CPU2017 是 CPU 通用计算的事实标尺，看 base、看 rate vs speed
SPECpower / SPECjbb / SPECstorage 各有领域
TPC-C / tpmC 在合同里仍重要，实际选型用 HammerDB / sysbench
数据库选型不能只看 benchmark，必须 POC 真实数据
看曲线、看 P99、看长时间持续，不只看峰值

下一篇专题讲 HPC 基准——HPL、HPCG 与 TOP500 的实战。

09-基准测试与认证

#SPEC CPU #TPC-C #HammerDB #tpmC

HPC 基准 —— HPL、HPCG 与 TOP500 上一篇

基准测试体系概览 —— TPC、SPEC、TOP500 与 MLPerf 下一篇