基于华为云 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直接反映算力。--threads1单线程串行测的是「单核」的 raw 算力--threads88 线程并发测的是「整机 8 逻辑核」能吃到多少吞吐报告里的avg / 95th percentile / max是单次事件耗时秒用来评估稳定性如果 avg 很低但 max 很高说明大部分时候快、偶尔被卡典型的多租户噪声。sysbench memory则测内存带宽--memory-operread是纯顺序读--memory-operwrite是「读一行写一行」的拷贝型写。两者带宽的差距本身就是内存子系统特性的体现后面细讲。2. 实验环境与上篇一致四节点位于同一 VPC 子网192.168.0.0/24节点弹性公网 IP私有 IP规格系统node1113.47.6.41192.168.0.2528vCPU/16GiBUbuntu 24.04.4 LTSnode2124.70.93.52192.168.0.648vCPU/16GiBUbuntu 24.04.4 LTSnode31.94.220.182192.168.0.2418vCPU/16GiBUbuntu 24.04.4 LTSnode4124.70.102.139192.168.0.1508vCPU/16GiBUbuntu 24.04.4 LTSCPU 拓扑来自lscpuThread(s) per core: 2 × Core(s) per socket: 4 × Socket(s): 1即 4 物理核 8 逻辑线程超线程开启标识General Purpose Processor 2.0GHzKVM 虚拟化。3. 实操安装与命令先在四节点装好 sysbench用上篇的 fanout 工具并行装# 并行安装 sysbenchPYTHONPATHdeps python tools/fanout.py allapt-get update -y apt-get install -y sysbench# 单线程 CPUPYTHONPATHdeps python tools/fanout.py all\sysbench cpu --cpu-max-prime20000 --threads1 --time15 run 2/dev/null | grep -E events per second|95th percentile# 8 线程 CPUPYTHONPATHdeps python tools/fanout.py all\sysbench cpu --cpu-max-prime20000 --threads8 --time15 run 2/dev/null | grep -E events per second|95th percentile# 内存读8 线程块 1KiBPYTHONPATHdeps python tools/fanout.py all\sysbench memory --memory-operread --threads8 --memory-block-size1K --memory-total-size50G run 2/dev/null | grep MiB# 内存写8 线程PYTHONPATHdeps python tools/fanout.py all\sysbench memory --memory-operwrite --threads8 --memory-block-size1K --memory-total-size50G run 2/dev/null | grep MiB--cpu-max-prime20000保证每个事件足够重避免线程调度开销掩盖算力差异--time15跑 15 秒取稳态均值。4. 真实输出来自 results/01_cpu_bench.txt、02_mem_bench.txt4.1 CPU 单线程 vs 8 线程节点单线程 eps单线程 95th(ms)8 线程 eps8 线程 95th(ms)加速比node11634.950.627196.621.124.40×node21631.770.627201.601.124.41×node31620.310.637193.911.124.44×node41628.420.627200.901.144.42×原始片段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 线程max16.11、node3 的max25.10——远高于 avg(1.11)。这正是多租户噪声的痕迹绝大多数事件 1.1ms 完成偶尔被宿主机调度拖到十几甚至二十几毫秒。4.2 内存读写带宽8 线程节点写带宽 (MiB/s)写带宽 (GiB/s)读带宽 (MiB/s)读带宽 (GiB/s)node145208.1244.1227705.88222.4node244507.0743.5246378.79240.6node353120.4351.9245266.98239.5node454533.7753.3245467.90239.7原始片段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 eps8 线程稳定 ~7193–7202 eps加速比仅约 4.4×远不到 8 倍。原因在拓扑里写得很清楚这是4 物理核 超线程。8 个逻辑线程实际跑在 4 个物理核上每核的两个超线程共享同一套执行单元ALU、FPU、缓存端口。4 个物理核提供约 4× 的算力这部分是「实打实」的超线程再贡献一部分吞吐但两个兄弟线程抢同一执行单元理想情况下只能再多挤 ~10%–30%远小于线性4.4× 的实测结果正好落在「4 物理核 超线程增益有限」的预期区间内。观点看云主机规格别只数 vCPU要问清是「物理核」还是「超线程逻辑核」。同样是 8 vCPU4 物理核HT on和 8 物理核的算力上限差近一倍。FlexusX 这边是前者做算力密集任务时心里要有数。5.2 四节点一致性好说明什么四节点的单线程 eps 落在 1620–16358 线程落在 7193–7202偏差 1%。这种一致性说明两件事同一实例族、同规格的硬件底座高度同质实验可复现柔性算力的隔离性对稳态算力影响可控——没有哪台被邻居长期「偷走」算力。但要警惕max列的偶发尖刺node1 的 16ms、node3 的 25ms。稳态一致 ≠ 实时一致。如果你跑的是延迟敏感的在线服务这种尾部尖刺会直接体现在你接口的 p99 上。5.3 内存为什么「读」远大于「写」读带宽 ~227–246 GiB/s写带宽 ~44–53 GiB/s读是写的约 4.6–5.4 倍。这不是机器坏了而是 sysbench 内存测试的固有行为read模式是纯顺序加载streaming loadCPU 预取器能把读流水线喂满内存控制器全力发读命令write模式实际是「读一行、写一行」的拷贝read-for-ownership每写一个字节得先把对应缓存行从内存读进来于是每条写操作背后都藏着一次读。测量的「写入量」是 51200 MiB但总线实际搬运约 2 倍——所以「有效写带宽」被读操作摊薄了。换句话说50 GiB/s 的「写」测量值背后是接近 100 GiB/s 的总线流量。真实的内存访问你写的业务代码大多是读多写少或读写混合会更接近「读」的那一侧。这个差距提醒我们用 sysbench 的 memory 子项做绝对值对比时要讲清口径别拿「写 44GiB/s」去和别人的「读 200GiB/s」比。5.4 用 95th 百分位看稳定性单线程 95th ≈ 0.62ms8 线程 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. 选型与成本建议结合本次实测给决策三条建议场景建议算力密集型编译、转码、数值计算认准物理核数别被 vCPU 数误导本规格 4 物理核在 8 线程下约 7200 eps估算任务量时按 4 核算更稳。延迟敏感型在线服务关注max尖刺若 p99 不可接受考虑关闭超线程或选独占/独享型实例牺牲一点密度换确定性。内存带宽敏感型缓存、内存计算读带宽 ~240 GiB/s 富余写受拷贝语义限制优化方向是减少写回、多用只读/只读多写少结构。成本观点柔性算力的「性价比」体现在按需配比 不用即关。本系列 4 节点若常驻每月是一笔固定开销但把它当「实验集群」用——跑完压测立刻停机——单位算力的钱能压到极低。自动化开关机是比选型更有效的省钱手段。7. 踩坑与排障events per second抖动大先确认没有别的进程在吃 CPUtop/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 与内存体检得到三个关键结论单线程 ~1620–1635 eps8 线程 ~7193–7202 eps加速比约 4.4×——因为 8 vCPU 实为 4 物理核 超线程别把 vCPU 当物理核算四节点稳态一致性极好偏差 1%但max偶发尖刺暴露了共享实例的尾部延迟代价内存读 ~227–246 GiB/s、写 ~44–53 GiB/s读远大于写源于 sysbench 写模式的「读改写」语义对比时要统一口径。下一篇我们用 fio 把云硬盘的 IOPS 和吞吐彻底扒开——顺序 vs 随机、大块 vs 小块、iodepth 与 numjobs 的门道全在03-云硬盘IO压测.md。