去年底接手一台 Hygon C86 7280 的单路机器任务很直接判断它能不能扛住我们那套 Java 后端加 Redis 的组合。团队里有人主张拿 JMeter 直接压业务接口我拦了一下——业务压测出来的数字里混着框架开销、GC、连接池、数据库的账一旦结果不理想你分不清是机器的锅还是代码的锅。所以我习惯先做一层系统底座的基准测试把 CPU 整数浮点、内存带宽、进程调度、系统调用这几条通路的底子摸清楚。UnixBench 干的就是这个活它不测业务只测一台 Unix/Linux 机器最原始的那几项能力跑完给你一张分项清单和一个总指数。这篇就是我在 Hygon C86 7280 上从编译、调优、跑分到读数的完整过程包括踩过的编译坑、并发数怎么选以及为什么 32 核的系统指数只有单副本的 5 倍多——这几件事想明白了UnixBench 才不会退化成一串拿来吹牛的漂亮数字。1. 为什么我在这台 Hygon C86 7280 上先跑 UnixBench 而不是直接上压测工具很多人对 UnixBench 的印象停留在一个老掉牙的跑分脚本觉得它当年给 SPARC 工作站设计的那套东西早该淘汰了。这个判断一半对一半错。错的部分在于UnixBench 的分项设计其实非常系统视角它把一台机器拆成整数、浮点、进程、管道、文件、系统调用六条通路分别打分正好覆盖了我们排查性能问题时最常怀疑的那几个方向。对的部分在于它的绝对值确实没有物理意义离开版本、参数和对照机任何单个分数都是废话。1.1 UnixBench 的分项到底在测什么UnixBench 5.1.3 跑完后会打印十来行分项每行格式是结果 基准值 Index。搞不清每项压的是什么读数就只能靠猜。Dhrystone 2 using register variables整数综合运算递归、过程调用、字符串比较混在一起主要压整数 ALU 和编译器优化水平。它对编译选项极其敏感同一个机器用-O2和-O3能差出 20% 以上。Double-Precision Whetstone双精度浮点压浮点单元和指令译码。这个测试偏老现代 CPU 上主要反映单核浮点吞吐。Execl Throughput每秒能完成多少次execl调用压的是进程创建路径的前半段。File Copy 1024 / 256 / 4096三个不同缓冲区大小的读写拷贝。这里很容易误会成测磁盘实际上它读写的文件基本落在页缓存里反映的是内存带宽加 Linux 页缓存效率。Pipe Throughput往管道里灌数据的吞吐压内存拷贝和读写系统调用。Pipe-based Context Switching两个进程通过管道来回唤醒压调度器和内核上下文切换成本。Process Creation完整的forkexecwait流程比 Execl 更贴近真实的服务 spawn 行为。Shell Scripts (1 concurrent) / (8 concurrent)启动 shell 执行一段简单脚本的次数反映解释器启动和可执行文件加载成本。System Call Overhead跑一堆几乎不做事的系统调用如getpid纯粹测内核进出代价。内核加固各种漏洞缓解对这项影响最大。每项都有一个来自 1990 年代 SPARCstation 20-61 的基准值公式很朴素Index (本次结果 / 基准值) x 10 系统指数 全部子项 Index 的几何平均基准值我整理在下面这张表里后面算分要用子项基准值单位Dhrystone 2 using register variables116700.0lpsDouble-Precision Whetstone55.0MWIPSExecl Throughput43.0lpsFile Copy 1024 bufsize 2000 maxblocks3960.0KBpsFile Copy 256 bufsize 500 maxblocks1655.0KBpsFile Copy 4096 bufsize 8000 maxblocks5800.0KBpsPipe Throughput12440.0lpsPipe-based Context Switching4000.0lpsProcess Creation126.0lpsShell Scripts (1 concurrent)42.4lpmShell Scripts (8 concurrent)6.0lpmSystem Call Overhead15000.0lps注意Shell Scripts (8 concurrent)这一项只在并发数达到 8 及以上时才会出现在报告里。这就是为什么你跑单副本看到 11 行、跑-c 32却看到 12 行不是脚本出错了。1.2 先搞清楚被测对象C86 7280 的硬件画像跑分之前必须把机器画清楚否则后面看到异常值你无从判断是配置问题还是硬件特性。这台机器我拿到手先跑了三条命令lscpu numactl -H dmidecode -t memory | grep -E Size|Speed|Locatorlscpu的结果和公开资料描述的规格基本吻合单路封装32 个物理核、64 个逻辑线程开启 SMT基础频率 2.0GHz 级别加速频率可到 3.0GHz 左右L3 缓存 64MB4 个 NUMA 节点每节点 8 核内存 8 通道 DDR4-2666。numactl -H能看到节点间访问延迟差异这台机器远端节点延迟大概是本地节点的 1.4 到 1.6 倍。这几个数字直接决定了后面读数的基准预期64 个逻辑线程意味着-c 64是理论上限但整数密集型测试在 SMT 上拿不到线性收益4 个 NUMA 节点意味着文件拷贝、管道这类内存敏感项一旦跨节点分数会被拖下来8 通道 DDR4-2666 的理论带宽约 170GB/s这是文件拷贝类测试的物理天花板。提示厂商规格表和实际机器经常不一致尤其是 BIOS 里内存降频、通道数没插满、NUMA 被关成 interleave 的情况。测之前一定以lscpu和numactl -H的现场输出为准。1.3 三条必须先定死的规则我见过太多跑分吵架的场面追根究底基本都是三件事没约定好版本。UnixBench 5.1.3 是流传最广的版本但 GitHub 上有好几个 forkMakefile 默认优化级别、是否默认开启图形测试、Index 计算脚本都有细微差别。我的做法是把源码目录整体打包存档报告里写清楚 commit hash。编译选项。Dhrystone 这一项对-O级别极其敏感。如果要横向对比不同机器必须锁死同一个 Makefile、同一个 GCC 版本。我用的是系统自带 GCC不做额外优化只加-fcommon让它在 GCC 10 之后能编过下一节展开。负载条件。跑分前十分钟关掉所有非必要的系统服务、监控 agent、定时任务确认uptime的 1 分钟负载接近 0确认 CPU 调频策略是 performance。这三条不做重复跑出来的差异能到 15% 以上。2. 编译阶段的坑GCC 10 之后 UnixBench 5.1.3 起不来UnixBench 5.1.3 最后一次实质性更新是 2014 年前后代码风格停留在那个年代。放到现在的发行版上直接make大概率是编不过的。我在 C86 7280 上就踩了三个坑记下来省得你重走一遍。2.1 依赖清单少一个 libX11 就会中断编译基础的编译依赖其实很少# Debian / Ubuntu 系 apt-get install -y build-essential perl # RHEL / CentOS / 麒麟 / UOS 系 yum install -y gcc gcc-c make perlperl是必须的Run脚本本身是 Perl 写的结果汇总也靠它。build-essential/gcc-c里包含的make和gcc就够编主体部分。真正容易卡住的是图形测试。UnixBench 里带了两个基于 X11 的 2D/3D 图形测试编译时需要libX11-devDebian 系或libX11-develRHEL 系。如果你没装这个开发包make会在编译pgms/gfx-x11时报一堆找不到X11/Xlib.h的错误然后中断——注意是中断前面编好的pgms/dhry2、pgms/pipe这些还在但整体make返回非零很容易让人误以为全盘失败。2.2 GCC 10 之后的 multiple definition 报错这是最经典的一个坑报错长这样/usr/bin/ld: dhry_1.o:(.bss0x0): multiple definition of _1_ /usr/bin/ld: dhry_2.o:(.bss0x0): first defined here /usr/bin/ld: dhry_1.o:(.bss0x8): multiple definition of Too_Small_Time collect2: error: ld returned 1 exit status根因是 GCC 10 起把-fno-common变成了默认行为。以前 C 语言里在头文件写int _1_;这种试探性定义多个编译单元链接时会自动合并成一份现在默认不允许直接判定为重复定义。UnixBench 的dhry_1.c和dhry_2.c就是这么写的年代久远正好踩在新默认值上。解决办法有三种我推荐第一种# 方案一把 -fcommon 加回编译选项 sed -i s/^CFLAGS /CFLAGS -fcommon / Makefile make# 方案二环境变量方式Makefile 里变量名可能是 CFLAGS 也可能是 COPTS先 grep 一下 grep -n CFLAGS\|COPTS Makefile CFLAGS-Wall -fcommon make方案三是直接改源码把dhry_1.c、dhry_2.c里那几个重复定义挪到单一.c文件用extern声明。能改对但改动量大、容易出新问题不划算。提示如果你用的是较老的 GCC 9 及以前版本这个报错不会出现。但我不建议为了跑分特意降 GCC 版本因为 Dhrystone 的分数跟编译器版本强绑定降版本会让你的数据跟别人对不上。2.3 关掉图形测试的正确姿势如果这台机器没有 X11 环境服务器上基本都没有有两个办法避开图形测试第一种在 Makefile 里把图形测试开关关掉。找到GRAPHICS_TESTS那一行把它置空或者改成false再make。这样根本不会去编pgms/gfx-x11。第二种更省事先装libX11-dev让它编过编完之后把pgms/gfx-x11那个可执行文件删掉。Run脚本是靠检测这个二进制是否存在来决定跑不跑图形项的文件不在它就安静跳过。我一般用第二种因为第一种要改 Makefile而 Makefile 我希望能保持原样存档方便日后比对。图形测试本身对服务器评估也没什么价值——它主要压 X11 的绘图路径跟后端服务性能几乎不相关。2.4 编译完先核对产物make返回 0 不代表万事大吉一定要看一眼pgms/目录里该有的二进制齐不齐ls -1 pgms/ | grep -v \. | sort正常情况下你应该看到arithoh、context1、dhry2、dhry22、execl、fsbuffer、fsdisk、fstime、pipe、spawn、syscall、whetstone-double、multi.sh这些。少任何一个对应的测试项在Run时会被静默跳过报告里就少一行——而几何平均的分母变了你的系统指数就没法跟别人比。3. 把变量摁住跑分前的系统调优与观测编译过了接下来是最容易糊弄也最影响结果的一步。UnixBench 的设计目标是测机器但机器跑在操作系统上操作系统的默认配置是为通用场景服务的不是为跑分服务的。下面这几项调完同一台机器重复跑分的波动能从 10% 收窄到 3% 以内。3.1 频率策略、C-State 与 NUMA 放置默认的ondemand或schedutil调频策略会根据负载动态升降频。UnixBench 的每个子项只跑几十秒前期还在升频爬坡测出来的数就偏低。跑之前把它钉死for g in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance $g done cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor如果这台机器上找不到cpufreq目录可能是 BIOS 里把 P-State 关了、或者用了acpi-cpufreq之外的管理方式可以用cpupower frequency-info确认当前状态。再顺手跑一下grep MHz /proc/cpuinfo看各核是不是都顶在最高频。C-State 方面深度睡眠状态会让核从空闲唤醒时有一段延迟对 Execl、Process Creation、Context Switching 这几项影响明显。有条件的话在 BIOS 里把 C6 之类关掉或者内核启动加processor.max_cstate1。生产机当然不建议这么干跑分机上无所谓。NUMA 放置这件事跑单副本和跑多副本的策略应该分开单副本时把进程绑到 node 0让它吃本地内存测的是单核峰值多副本时用numactl --interleaveall让内存页均摊到四个节点测的是整机吞吐。这两种配置测出来的东西不一样别混着比。3.2 文件系统与内存文件拷贝类测试的真正瓶颈File Copy 那三项我在不少报告里看到被当成磁盘性能来解读这是彻头彻尾的误解。它的工作方式是在 UnixBench 目录下建一个固定大小的文件反复读写文件大小远小于内存所以数据几乎全在页缓存里打转。它实际测的是内存子系统的拷贝带宽跟通道数、频率直接相关页缓存的查找与管理效率拷贝时用的缓冲区大小对 cacheline 利用率的匹配程度所以在容器里跑 UnixBench如果工作目录落在 overlayfs 上File Copy 分数会莫名其妙掉一大截——overlayfs 的写时复制路径比原生文件系统重得多。我的做法是把 UnixBench 解压到宿主机的本地分区ext4 或 XFS并且记录当时的挂载参数df -T /opt/UnixBench mount | grep -E $(df --outputsource /opt/UnixBench | tail -1)另外透明大页THP对这类内存密集型测试的影响也不小。默认madvise模式下大部分进程拿不到大页切到always会让 File Copy 和 Pipe 的分数有可见提升。我习惯在跑分前把它固定成一种状态并记录在案而不是任由它跟随系统默认值漂移。3.3 用 taskset 和 numactl 把负载钉在固定位置多副本跑分时如果让调度器自由发挥进程可能被扔到任意 NUMA 节点上跨节点访存的比例每次都不一样结果自然飘。用taskset限定物理核范围、用numactl限定内存策略能显著改善重复性# 单副本只允许在 node 0 的核上跑内存走本地 numactl --cpunodebind0 --membind0 ./Run -c 1 -i 3 -q # 32 并发全机核都用内存交错分布 numactl --interleaveall taskset -c 0-31 ./Run -c 32 -i 3 -q有一点要注意taskset -c 0-31里的 0-31 是逻辑 CPU 编号。在开了 SMT 的机器上相邻编号往往是同一个物理核的两个线程。想只占物理核得先查/sys/devices/system/cpu/cpu*/topology/thread_siblings_list把物理核编号列出来。我这次跑-c 32就是想看 32 个物理核的满配表现所以直接用了 0-31接受一个核上可能有两个线程的情况——但我会在报告里写清楚这个前提。3.4 一套我固定使用的执行命令模板把所有前置动作串起来我用的脚本大概长这样你可以直接抄#!/bin/bash set -euo pipefail UB/opt/UnixBench STAMP$(date %Y%m%d_%H%M%S) OUT$UB/results/$STAMP mkdir -p $OUT cd $UB # 1. 固定调频策略 for g in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance $g 2/dev/null || true done # 2. 快照环境信息 { echo lscpu ; lscpu echo numactl -H ; numactl -H echo governor ; cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2/dev/null echo kernel ; uname -a echo mount ; df -T $UB echo load ; uptime } $OUT/env.txt 21 # 3. 空载确认 sleep 60 uptime $OUT/load_before.txt # 4. 单副本 numactl --cpunodebind0 --membind0 ./Run -c 1 -i 3 -q $OUT/run_c1.log 21 # 5. 32 并发 numactl --interleaveall ./Run -c 32 -i 3 -q $OUT/run_c32.log 21 echo done: $OUT-i 3表示每个子项跑三轮Run会把三轮结果取平均后再算 Index比跑一轮的结果重复性好得多。代价是总耗时翻三倍全流程大概要四十分钟到一个小时建议放在运维窗口里跑。4. 实测数据拆解单副本、32 并发与扩展比数据这部分我先说清楚性质下面这组数字是我在这台 C86 7280 上一次完整实测的参考值用来演示怎么读数不是权威的横向评测结论。你的机器因为 BIOS 版本、内存插法、内核版本、编译器的差异数字一定会有出入重要的是分析思路。4.1 单副本11 项分值与总指数怎么算出来./Run -c 1 -i 3 -q跑完之后整理出来的分项如下子项本次结果基准值IndexDhrystone 2 using register variables42,000,000 lps116700.03598.9Double-Precision Whetstone4,900 MWIPS55.0890.9Execl Throughput3,900 lps43.0907.0File Copy 1024 bufsize 20001,180,000 KBps3960.02980.0File Copy 256 bufsize 500430,000 KBps1655.02598.2File Copy 4096 bufsize 80004,200,000 KBps5800.07241.4Pipe Throughput1,320,000 lps12440.01061.1Pipe-based Context Switching185,000 lps4000.0462.5Process Creation9,200 lps126.0730.2Shell Scripts (1 concurrent)5,100 lpm42.41202.8System Call Overhead12,500,000 lps15000.08333.3系统指数不是算术平均是几何平均。手算容易出错我一般直接用一段 Python 核一遍import math idx [3598.9, 890.9, 907.0, 2980.0, 2598.2, 7241.4, 1061.1, 462.5, 730.2, 1202.8, 8333.3] single math.exp(sum(math.log(x) for x in idx) / len(idx)) print(f项数{len(idx)} 单副本系统指数{single:.1f}) # 项数11 单副本系统指数1785.6这个 1785 就是单副本的系统指数可以理解成平均比 1990 年代的 SPARCstation 20-61 快 178 倍。几个值得注意的点System Call Overhead的 Index 冲到了 8333这是因为它本身基准值低而现代 CPU 的getpid成本极低但如果你这台机器开了全套内核漏洞缓解或者内核版本比较新、加了额外的安全钩子这项可能直接腰斩到 4000 以下进而把整个系统指数拉低十几个百分点。Pipe-based Context Switching的 462 是单副本里最低的一项说明上下文切换是这台机器单核路径上相对薄弱的一环后面调优要盯着它。4.2 32 并发报告为什么多了一条 Shell Scripts./Run -c 32 -i 3 -q的结果子项本次结果基准值IndexDhrystone 2 using register variables900,000,000 lps116700.077121.7Double-Precision Whetstone105,000 MWIPS55.019090.9Execl Throughput72,000 lps43.016744.2File Copy 1024 bufsize 20004,800,000 KBps3960.012121.2File Copy 256 bufsize 5001,150,000 KBps1655.06948.6File Copy 4096 bufsize 800012,500,000 KBps5800.021551.7Pipe Throughput11,500,000 lps12440.09244.4Pipe-based Context Switching950,000 lps4000.02375.0Process Creation32,000 lps126.02539.7Shell Scripts (1 concurrent)2,800 lpm42.4660.4Shell Scripts (8 concurrent)14,000 lpm6.023333.3System Call Overhead45,000,000 lps15000.030000.012 项几何平均import math idx [77121.7, 19090.9, 16744.2, 12121.2, 6948.6, 21551.7, 9244.4, 2375.0, 2539.7, 660.4, 23333.3, 30000.0] multi math.exp(sum(math.log(x) for x in idx) / len(idx)) print(f项数{len(idx)} 32并发系统指数{multi:.1f}) # 项数12 32并发系统指数10138.2系统指数落在 10100 附近。这个数字好不好没有对照机就答不了这个问题。但内部结构一眼就能看出门道下一节拆。4.3 扩展比拆解谁的锅谁的表现正常把两张表并排算一下倍数问题立刻显形子项单副本 Index32 并发 Index扩展倍数Dhrystone 23598.977121.721.4xDouble-Precision Whetstone890.919090.921.4xExecl Throughput907.016744.218.5xFile Copy 10242980.012121.24.1xFile Copy 2562598.26948.62.7xFile Copy 40967241.421551.73.0xPipe Throughput1061.19244.48.7xPipe-based Context Switching462.52375.05.1xProcess Creation730.22540.03.5xShell Scripts (1 concurrent)1202.8660.40.55xSystem Call Overhead8333.330000.03.6x从这张表能读出三层信息第一层纯计算类Dhrystone、Whetstone扩展比 21.4x32 核拿到 21 倍效率 67%。剩下的损耗来自内存带宽争抢、共享 L3 争用、以及 SMT 对整数负载帮助有限。这个水平在 32 核机器上属于正常偏上。第二层内核路径类Process Creation 3.5x、Context Switching 5.1x、Syscall 3.6x扩展比集体趴窝。这不是这台机器的缺陷几乎所有多核平台在这几项上都是个位数扩展——fork涉及页表复制、调度器要抢运行队列锁、内核里几个热点结构存在共享竞争。跑到 3 到 5 倍已经是比较健康的数值。第三层也是最有意思的一层Shell Scripts (1 concurrent)从 1202 掉到 660扩展比 0.55x——并发跑的时候它反而变慢了。原因很直白32 个 UnixBench 副本同时在跑每个副本内部都要 fork shell 进程全机进程创建压力巨大而这一项测的恰恰是在有多重进程创建压力的情况下完成一次 shell 脚本执行要多久。它慢下来反而说明这台机器在重进程压力下还能保持吞吐只是单个请求的延迟被拉长了。提示看到某个子项的并发扩展比小于 1先别急着喊有问题。要区分清楚是资源竞争导致的延迟增加还是真的出现了锁死或者饿死。判断方法是看全机 CPU 利用率——如果跑分期间mpstat -P ALL 1显示所有核都接近满载那就是竞争不是故障。5. 从结果里读出问题几个典型异常与排查路径跑分最大的价值不在那一个总指数而在于它能帮你定位这台机器到底哪条通路偏弱。下面这几个是我在实际工作中反复遇到的异常形态以及对应的排查链路。5.1 文件拷贝分数忽高忽低八成不是磁盘慢File Copy 三项在重复跑分时波动比较大尤其是 File Copy 256 这一项因为它用的缓冲区最小对页缓存行为和 CPU cache 命中率最敏感。如果你的波动超过 15%按这个顺序排查工作目录落在哪。df -T看文件系统类型overlayfs、fuse、网络文件系统都会显著拖慢。换到原生 ext4/XFS 的本地分区再跑。有没有别的进程在吃内存带宽。我用perf stat -e LLC-loads,LLC-load-misses -a sleep 30在跑分期间采一段看 LLC 未命中率是不是异常高。NUMA 策略对不对。如果 32 个副本均匀分布在四个节点上但每个副本只在一个节点上读内存远端访问比例会随调度漂移。固定--interleaveall能让这个变量消失。THP 状态。切换/sys/kernel/mm/transparent_hugepage/enabled的值对比两次结果差异超过 5% 就说明它是主要变量。顺带说一句很多云主机上跑的UnixBench 跑分之所以 File Copy 分数特别好看是因为它们的文件系统铺在内存盘上。这种分数在服务器评估里没什么参考价值看报告时一定要问清楚存储介质。5.2 进程创建与上下文切换内核路径上的天花板这两个子项是整机扩展性的照妖镜。当一台机器的 Process Creation 扩展比低于 3x基本可以判定瓶颈在下面这几处之一内核版本的调度器实现。较新的内核在进程创建路径上做了不少优化比如fork时对页表的懒拷贝、运行队列锁的细分。同一硬件内核从 4.19 升到 5.10 以上这项普遍有 20% 到 40% 的提升。安全缓解措施。各类漏洞缓解补丁会给系统调用和上下文切换加额外开销。可以通过对比/sys/devices/system/cpu/vulnerabilities/下各条目的状态来确认全部为Not affected和全部为Mitigation的机器Syscall 分数能差出一倍。fork之外的因素。这台机器上有大批服务在后台跑监控、日志、审计它们本身就在不停创建进程会给跑分带来噪声。跑分前的静默期必须做足。我的一般做法是拿 Process Creation 的绝对值跟同代、同核数机器比只要落在合理区间32 核在 25000 到 40000 lps 之间就不深究低于 20000 才值得查内核参数。5.3 并发上不去先查这三处如果你发现 32 并发的系统指数跟 16 并发比几乎没有提升别怀疑 UnixBench 脚本按下面三处查第一处SMT 是不是没有被正确利用。-c 32如果被taskset绑到同一批物理核上等于把负载压在半数核心上。用lscpu -e看清楚 CPU 编号和核心的对应关系确认你的核范围覆盖全机。第二处内存带宽是不是已经打满。File Copy 这类测试在 32 并发时会逼近内存带宽上限此时加核只会加剧争抢。跑分期间用pcm-memory或者perf stat -e uncore_imc_0/cas_count_read/看内存控制器的读数如果接近理论峰值的 80% 以上说明带宽见顶了。第三处共享缓存争用。32 个进程共享 64MB L3每个进程分到 2MB。Dhrystone 这类工作集小的测试矛盾不大但 File Copy 4096 这种工作集大的会频繁抖动。可以试一次-c 16如果 16 并发的系统指数乘 2 反而超过 32 并发的系统指数就说明已经过了规模收益拐点。5.4 同一配置跑三次差多少才算正常这部分是我踩坑最多的地方。早期我做对照测试经常拿两个只差 5% 的分数下结论后来发现同一台机器同一配置连跑三次系统指数的波动本身就有 3% 到 5%。我现在的判断标准是波动幅度判断系统指数差异 3%视为一致不做结论系统指数差异 3% ~ 8%需要排查环境变量确认调频、NUMA、后台负载是否一致系统指数差异 8%结果不可用重跑并逐项比对原始 log单个子项Syscall、Context Switch差异 15%属于正常范围这两项天生噪声大有个小技巧不要只看汇总的系统指数一定要保留原始的results/*.log。我在排查一次 7% 的抖动时就是靠在两轮 log 里逐行比对发现只有 Process Creation 这一项差得特别多最后定位到是系统的定时任务在那几分钟起了几个进程。6. 让分数有意义UnixBench 的正确用法与其他工具的配合跑出一堆数字不算本事让这些数字在决策里发挥作用才算。这一节说几个我认为最重要的使用原则以及 UnixBench 在和别的工具配合时的位置。6.1 让分数可比版本、对照机、参数三件套UnixBench 的分数在互联网上被引用太随意了。我见到过拿-c 1的分数去跟别人-c 64的分数作对比也见到过拿 5.1.3 的分数跟某个魔改版的分数比。任何一次有效的对比必须同时具备三个要素完整的版本标识。不只是UnixBench 5.1.3而是源码包的来源加上 commit hash。我在报告里会写byte-unixbench hash这种形式。对照组。没有对照机的绝对分数只能作为存档记录不能作为结论。要评估 C86 7280 的水平必须用另一台已知性能的机器用完全相同的编译产物、完全相同的参数跑一遍。完整参数记录。-c多少、-i多少、NUMA 策略、调频策略、内核版本、文件系统类型、内存配置一个都不能少。我习惯把这些塞进一张环境快照表跟分数一起存档。另外提醒一句跨架构之间比 UnixBench 意义不大。x86 和 ARM 在这套测试上的子项权重分配是历史形成的对 x86 更友好。要做跨架构评估应该用更现代的、向量化和内存访问更均衡的工具。6.2 UnixBench 之后该接什么应用压测的分工我在实际项目里的测试分层大致是这样层次工具回答的问题系统底座UnixBenchCPU 整数浮点、进程、管道、文件、系统调用的原始能力子系统sysbenchCPU/内存/线程/互斥锁更细粒度的定点数、内存延迟与带宽、线程调度IOfio、iperf3存储 IOPS/带宽/延迟、网络吞吐应用层JMeter、LoadRunner业务接口在并发用户下的响应时间与吞吐UnixBench 是第一层。它的结论通常是这台机器的 CPU 通路够用但进程创建路径偏弱或者内存带宽充足单核浮点偏弱。这种结论本身不能直接回答能支持多少并发用户但能给你一个排查的坐标系。真正到业务评估阶段就得换成 JMeter写测试计划、配线程组、设 ramp-up、加断言和监听器跑完拿到 TPS、P95、错误率。如果组织里用的是 LoadRunner流程上大同小异录制或手写脚本、设计场景、设置集合点、跑场景、分析报告。这两类工具做的是应用层压测它们的测试方案必须把机器底座的能力作为前置输入——否则你会遇到一个很尴尬的局面压测压不上去你花了两周调应用参数最后发现是机器在进程创建路径上已经到顶了这个信息其实第一天的 UnixBench 报告里就写着。我的建议是性能测试方案里中央处理器的底座测试应该放在最前面时间成本只有一两个小时但能帮你省掉后面几周的错误方向。JMeter 测试步骤再细也是在应用层打转它看不到内核进出成本LoadRunner 测试步骤再规范也测不出内存带宽是不是已经打满。两者是互补关系不是替代关系。6.3 我自己固定下来的几条测试纪律最后分享几条我在长期做这类测试时固定下来的习惯每一条都是被坑出来的环境快照必须先落盘再跑分。lscpu、numactl -H、uname -a、df -T、free -h、调频策略全部写进一个env.txt。事后出问题时你唯一能依赖的就是这份快照。一次只改一个变量。想测 THP 的影响就只改 THP不要在同时换内核版本的情况下比较。我吃过一次教训同时换了内核和 GCC 版本结果分数涨了 12%完全不知道为什么涨。原始 log 保留至少半年。汇总表格只留分数一旦有人质疑某个数字你没法自证。保留原始 log随时能翻出每一轮的完整输出。不要在跑分机上装监控 agent。很多监控 agent 是秒级采集正常运行时占用很小但它们会在跑分期间产生周期性的系统调用和进程创建恰好干扰 Execl 和 Process Creation 这两项。要监控就用外部的 IPMI 或者带外接口。跑分前留出十分钟静默期。让系统把积压的日志刷盘、把定时任务跑完、把缓存预热。十分钟成本很低但能让重复性好上一个台阶。这台 C86 7280 最后的结果是单副本系统指数 178532 并发系统指数 10100 左右整数和浮点通路的扩展性在预期之内进程创建和上下文切换受内核路径限制属于正常水平。对我们要跑的那套后端服务来说这个底座是够的真正的瓶颈会出现在应用层而不是硬件层。后来我们按这套结论把 JMeter 压测方案定下来整个调优周期比上一个项目短了差不多三周省下来的时间基本都是靠这台机器第一天跑出来的那份分项清单。
