基于华为云 FlexusX 四节点集群的云计算全栈实操（二）：云虚拟机性能基准（sysbench CPU/内存深度体检）

基于华为云 FlexusX 四节点集群的云计算全栈实操（二）：云虚拟机性能基准（sysbench CPU/内存深度体检）

上篇我们把四节点实验室的地基打好了（自动化运维基建）。本篇进入 IaaS 层的真正硬核——给云虚拟机做性能基准测试。云厂商宣传页上写的「8 vCPU」，到底值不值这个钱？我们用 sysbench 把 CPU 和内存的真实成色测出来。

0. 引子：宣传页的数字，要自己验

买云主机时，没人会怀疑「8 vCPU / 16GiB」是假的。但「算力」是一个连续谱，不是开关。同一个规格，不同实例族、不同宿主机负载下，实测性能可能差出 20% 以上。更关键的是——你要知道自己的 8 线程为什么跑不出 8 倍单线程，否则你永远不知道瓶颈在物理核、超线程，还是邻居噪声。

《深入浅出云计算》里把「计算」拆成「算力密度、弹性、隔离性」三个维度。本篇的 sysbench 测试，正是给「算力密度」和「隔离性」做一个可量化的体检。

1. 理论预热：sysbench 到底在测什么

sysbench cpu做的是一件极简的事：反复执行一个素数判定（质数计算）的纯 CPU 密集任务，单位时间能完成多少次事件（events per second, eps）直接反映算力。

• --threads=1：单线程串行，测的是「单核」的 raw 算力；
• --threads=8：8 线程并发，测的是「整机 8 逻辑核」能吃到多少吞吐；
• 报告里的avg / 95th percentile / max是单次事件耗时（秒），用来评估稳定性：如果 avg 很低但 max 很高，说明大部分时候快、偶尔被卡（典型的多租户噪声）。

sysbench memory则测内存带宽：--memory-oper=read是纯顺序读，--memory-oper=write是「读一行写一行」的拷贝型写。两者带宽的差距，本身就是内存子系统特性的体现（后面细讲）。

2. 实验环境

与上篇一致，四节点位于同一 VPC 子网192.168.0.0/24：

CPU 拓扑（来自lscpu）：Thread(s) per core: 2 × Core(s) per socket: 4 × Socket(s): 1，即 4 物理核 + 8 逻辑线程（超线程开启），标识General Purpose Processor @ 2.0GHz，KVM 虚拟化。

3. 实操：安装与命令

先在四节点装好 sysbench（用上篇的 fanout 工具并行装）：

# 并行安装 sysbenchPYTHONPATH=deps python tools/fanout.py all'apt-get update -y && apt-get install -y sysbench'# 单线程 CPUPYTHONPATH=deps python tools/fanout.py all\'sysbench cpu --cpu-max-prime=20000 --threads=1 --time=15 run 2>/dev/null | grep -E "events per second|95th percentile"'# 8 线程 CPUPYTHONPATH=deps python tools/fanout.py all\'sysbench cpu --cpu-max-prime=20000 --threads=8 --time=15 run 2>/dev/null | grep -E "events per second|95th percentile"'# 内存读（8 线程，块 1KiB）PYTHONPATH=deps python tools/fanout.py all\'sysbench memory --memory-oper=read --threads=8 --memory-block-size=1K --memory-total-size=50G run 2>/dev/null | grep "MiB"'# 内存写（8 线程）PYTHONPATH=deps python tools/fanout.py all\'sysbench memory --memory-oper=write --threads=8 --memory-block-size=1K --memory-total-size=50G run 2>/dev/null | grep "MiB"'

--cpu-max-prime=20000保证每个事件足够重，避免线程调度开销掩盖算力差异；--time=15跑 15 秒取稳态均值。

4. 真实输出（来自 results/01_cpu_bench.txt、02_mem_bench.txt）

4.1 CPU 单线程 vs 8 线程

原始片段（node1）：

### sysbench CPU single-thread ### events per second: 1634.95 min: 0.59 avg: 0.61 max: 0.72 95th percentile: 0.62 ### sysbench CPU 8-thread ### events per second: 7196.62 min: 0.60 avg: 1.11 max: 16.11 95th percentile: 1.12

注意 node1 的 8 线程max=16.11、node3 的max=25.10——远高于 avg(1.11)。这正是多租户噪声的痕迹：绝大多数事件 1.1ms 完成，偶尔被宿主机调度拖到十几甚至二十几毫秒。

4.2 内存读写带宽（8 线程）

原始片段（node3 写 / node2 读）：

### MEM write (8t) ### Total operations: 51200 (53120.43 per second) 51200.00 MiB transferred (53120.43 MiB/sec) ### MEM read (8t) ### Total operations: 51200 (246378.79 per second) 51200.00 MiB transferred (246378.79 MiB/sec)

5. 深度解读（重点）

5.1 为什么 8 线程不是单线程的 8 倍？

单线程稳定 ~1620–1635 eps，8 线程稳定 ~7193–7202 eps，加速比仅约 4.4×，远不到 8 倍。原因在拓扑里写得很清楚：这是4 物理核 + 超线程。8 个逻辑线程实际跑在 4 个物理核上，每核的两个超线程共享同一套执行单元（ALU、FPU、缓存端口）。

• 4 个物理核提供约 4× 的算力，这部分是「实打实」的；
• 超线程再贡献一部分吞吐，但两个兄弟线程抢同一执行单元，理想情况下只能再多挤 ~10%–30%，远小于线性；
• 4.4× 的实测结果，正好落在「4 物理核 + 超线程增益有限」的预期区间内。

观点：看云主机规格，别只数 vCPU，要问清是「物理核」还是「超线程逻辑核」。同样是 8 vCPU，4 物理核（HT on）和 8 物理核的算力上限差近一倍。FlexusX 这边是前者，做算力密集任务时心里要有数。

5.2 四节点一致性好，说明什么？

四节点的单线程 eps 落在 1620–1635，8 线程落在 7193–7202，偏差 < 1%。这种一致性说明两件事：

1. 同一实例族、同规格的硬件底座高度同质，实验可复现；
2. 柔性算力的隔离性对稳态算力影响可控——没有哪台被邻居长期「偷走」算力。

但要警惕max列的偶发尖刺（node1 的 16ms、node3 的 25ms）。稳态一致 ≠ 实时一致。如果你跑的是延迟敏感的在线服务，这种尾部尖刺会直接体现在你接口的 p99 上。

5.3 内存为什么「读」远大于「写」？

读带宽 ~227–246 GiB/s，写带宽 ~44–53 GiB/s，读是写的约 4.6–5.4 倍。这不是机器坏了，而是 sysbench 内存测试的固有行为：

• read模式是纯顺序加载（streaming load），CPU 预取器能把读流水线喂满，内存控制器全力发读命令；
• write模式实际是「读一行、写一行」的拷贝（read-for-ownership）：每写一个字节，得先把对应缓存行从内存读进来，于是每条写操作背后都藏着一次读。测量的「写入量」是 51200 MiB，但总线实际搬运约 2 倍——所以「有效写带宽」被读操作摊薄了。

换句话说，50 GiB/s 的「写」测量值，背后是接近 100 GiB/s 的总线流量。真实的内存访问（你写的业务代码大多是读多写少或读写混合）会更接近「读」的那一侧。这个差距提醒我们：用 sysbench 的 memory 子项做绝对值对比时要讲清口径，别拿「写 44GiB/s」去和别人的「读 200GiB/s」比。

5.4 用 95th 百分位看稳定性

单线程 95th ≈ 0.62ms，8 线程 95th ≈ 1.12ms。8 线程下 95th 比单线程只慢约 1.8 倍——说明即便 8 线程抢 4 物理核，绝大多数事件仍能在 ~1.1ms 内完成，调度是健康的。真正该盯的是max：它由偶发的宿主机调度/中断引起，波动大、不可预测，是共享型实例的天然代价。

5.5 给你的算力一个直觉标尺

把 eps 换算成更直觉的东西：单线程 ~1630 eps 意味着「每秒可判定约 1630 次 20000 以内的素数」；8 线程 ~7200 eps 意味着整机一秒约 7200 次。如果你要算的工作是「单任务需 1630 次事件」，那么单线程要 1 秒、8 线程并行 4 个这样的任务约 1 秒（受 4 物理核限制）——并行度超过物理核数后，再多开线程也只是让单事件变慢（avg 从 0.61ms 升到 1.11ms），总吞吐不再线性增长。这正是「算力密度」的真实边界：你可以买很多 vCPU，但物理核才是硬通货。

6. 选型与成本建议

结合本次实测，给决策三条建议：

成本观点：柔性算力的「性价比」体现在按需配比 + 不用即关。本系列 4 节点若常驻，每月是一笔固定开销；但把它当「实验集群」用——跑完压测立刻停机——单位算力的钱能压到极低。自动化开关机，是比选型更有效的省钱手段。

7. 踩坑与排障

• events per second抖动大：先确认没有别的进程在吃 CPU（top/mpstat -P ALL 1），再确认是否落在宿主机繁忙时段。共享实例的基准建议多跑几次取中值。
• sysbench 版本差异：不同发行版自带版本参数名略有差别，本文命令在 Ubuntu 24.04 自带 sysbench 1.x 验证通过。
• 内存测试别把total-size设太小：太小会缓存命中，测不出真实带宽；本文 50G 远超 16GiB 内存，强制走真实内存通道（注意会真正占用时间，按需调整）。

8. 配套脚本

• ../tools/ssh_run.py、../tools/fanout.py：批量执行与并行扇出（见上篇）。
• ../scripts/：本篇命令可直接脚本化放这里，方便复跑。

9. 小结

本篇用 sysbench 给 FlexusX 四节点做了 CPU 与内存体检，得到三个关键结论：

1. 单线程 ~1620–1635 eps，8 线程 ~7193–7202 eps，加速比约 4.4×——因为 8 vCPU 实为 4 物理核 + 超线程，别把 vCPU 当物理核算；
2. 四节点稳态一致性极好（偏差 <1%），但max偶发尖刺暴露了共享实例的尾部延迟代价；
3. 内存读 ~227–246 GiB/s、写 ~44–53 GiB/s，读远大于写源于 sysbench 写模式的「读改写」语义，对比时要统一口径。

下一篇，我们用 fio 把云硬盘的 IOPS 和吞吐彻底扒开——顺序 vs 随机、大块 vs 小块、iodepth 与 numjobs 的门道，全在03-云硬盘IO压测.md。