1. 为什么我需要给KeyarchOS做一份精准跑分指南浪潮信息KeyarchOS后面统一叫KOS是我最近在服务器环境里用得比较多的操作系统。它基于Linux内核深度定制针对数据中心场景做了大量优化在虚拟化、容器、AI基础设施这些方向都有专门适配。但操作系统好不好用不能光看厂商宣传最终还得靠基准测试数据说话。UnixBench作为一款老牌的系统性能测试工具虽然出身“上古”但在衡量系统综合性能方面依然是行业里认可度最高的方案之一。我在多个国产操作系统上跑过UnixBench说句实话同样的硬件、同样的内核版本不同发行版跑出来的分数差距可能超出你的想象。这里的差距往往不是硬件不行而是系统默认参数的差异、编译器版本的不同、甚至调度策略的选择在起作用。所以如果你正在评估KOS的性能表现或者打算把KOS作为生产环境的底座一份可复现、可对比的UnixBench跑分流程是很有必要的。这篇内容面向的是三类读者一是刚接触KOS、想验证系统性能的运维新人二是需要在国产化平台做选型对比的技术负责人三是已经在用KOS、想优化跑分结果的进阶用户。我会把从下载安装包到解读测试报告的全过程拆开讲包括那些文档里不会写的细节和踩坑经验。无论你手里是x86服务器还是ARM架构的机器这套流程基本都能直接用。2. 跑分前的核心认知UnixBench到底在测什么2.1 综合性能测试的底层逻辑很多人在跑UnixBench时有个误解觉得分数高就代表系统快。实际上UnixBench衡量的是“系统作为一个整体”完成一系列模拟任务的能力它不只是跑CPU的浮点运算而是把文件操作、进程调度、内存分配、管道通信这些日常负载全部揉在一起算。它模拟的场景包括多任务并发、图形处理2D/3D、数据库类操作模式所以测出来的分数更接近“系统能不能扛住真实业务压力”的判断依据。UnixBench的核心机制是跑一组基础测试项每项测试跑完得到一个单独的得分然后用几何平均数汇总成最终的系统评分。几何平均数在这里是个很有讲究的选择——它不像算术平均那样会被个别极高值带偏能更公允地反映系统中各子系统的均衡表现。如果一个系统CPU很强但磁盘性能拉胯几何平均分就会被磁盘部分明显拖低这恰好符合我们对“整体性能”的直觉判断。2.2 为什么在KOS上跑分要特别注意系统优化状态KOS作为服务器操作系统在默认安装状态下就已经做了一些内核参数调优比如针对网络高并发场景调整了TCP缓冲区、针对NVMe存储优化了I/O调度器。这意味着在KOS上跑UnixBench时你测到的不是“裸硬件性能”而是“硬件KOS优化策略”的综合结果。这反而更接近生产环境的真实表现因为你在生产环境里用的就是这套默认配置。但这里有个关键细节如果你用默认配置跑出来分数不理想不能直接断定是系统有问题。先检查是不是测试方法的问题——比如是否用了图形界面环境UnixBench的2D/3D测试项在无显示器服务器上会得到异常低分、是否有其他进程抢占CPU、是否没有锁定CPU频率。这些干扰因素我在后面第四部分会详细展开。我见过太多人把跑分环境没搭好导致的分数暴跌错误归因到了操作系统头上。2.3 跑分结果的可比性前提UnixBench的分数只有在“控制变量”的前提下才有对比意义。你拿一台2路至强跑出来的分去和一台4路ARM服务器比绝对值没有意义同样别人用GCC 9编译的UnixBench和你用GCC 12编译的结果也不能直接画等号。因为UnixBench的源码在编译时依赖编译器优化级别不同编译器版本生成的可执行文件在部分测试项上能差出10%到20%。所以我在自己的测试环境里定了几条规矩统一用发行版自带的GCC版本编译、统一关闭Turbo Boost锁定频率、统一在最小化安装环境下运行、统一跑三轮取最优值。这些规矩听着繁琐但能保证你一周后、甚至一个月后再跑一次数据依然有横向对比的参考价值。3. 环境准备与安装从零开始搭好跑分环境3.1 安装包从哪拿三种来源一次说清楚需要说明的是UnixBench并不是KOS官方软件仓库里的默认包。很多时候你在搜索引擎里找“unixbench安装包下载”会找到一堆来路不明的压缩包为了安全起见我只推荐三个可信来源GitHub上的Byte-UnixBench项目这是目前社区维护最活跃的分支修复了一些老旧源码在ARM平台和新版GCC下的编译错误强烈推荐使用这个版本。系统软件仓库直接搜索部分Linux发行版把UnixBench打进了epel或contrib仓库你可以先执行sudo dnf search unixbench看看有没有现成包。有的话直接装最省事但要注意版本可能偏旧。官方源码包自行编译从原始网站下载源码包自己编译优点是最纯粹缺点是在新版内核和编译器下大概率遇到兼容性问题需要手动打补丁。我第一次在KOS上跑的时候走了不少弯路。先是图省事从某论坛下载了一个“绿色版”二进制包结果在KOS上一运行就报段错误折腾了半天发现是那个包只适配了glibc 2.23以下的旧系统。后来又试了从原始网站下的源码编译时在src/wait.h这个文件上报了类型冲突的错误。最后换了Byte-UnixBench版本一分钟编译通过跑分流程才正式走通。3.2 编译前的依赖安装在KOS上编译UnixBench需要的依赖非常简单本质就一个编译器工具链。可以一次性装齐sudo yum install -y gcc gcc-c make如果是更精简的环境只需要make和gcc这两个核心包即可大多数测试项不需要额外的库。但有个例外——如果你希望跑2D/3D图形测试项就需要安装X11相关的开发库否则编译时会直接跳过这几个测试项。服务器场景一般不需要所以我建议在跑分前先确认是否安装了图形库如果没有就直接接受跳过别为了补全测试项去装一整套图形环境反而污染跑分环境。装好依赖后用gcc --version确认编译器版本。我在KOS 5.x版本上默认拿到的是GCC 12.x这个版本编译UnixBench没有坑可以放心用。3.3 完整编译安装流程整个安装过程可以浓缩成三步# 第一步解压源码包 tar -zxvf Byte-UnixBench-5.1.3.tar.gz cd Byte-UnixBench-5.1.3 # 第二步执行编译 make # 第三步验证编译产物 ls -l Run编译完成后目录下会多出一个名为Run的可执行脚本这个脚本是用来启动测试的入口。另外还有个pgms目录里面存放编译好的二进制程序每个程序对应一类测试项。看到这些文件生成说明编译阶段已经完成。这里补充一个GMP和MPFR库的处理问题UnixBench的某些测试脚本会尝试检测这两个数学库并链接进去用于高精度计算测试。如果系统里没有对应的-devel包部分测试项会被自动跳过。我在KOS上实测不给系统装GMP和MPFR库只跑核心测试项并不会影响主要分数的可比性因为大家默认都会基于相同的依赖环境去对比。如果你的目标是做竞品对比建议和对方约定好同一个依赖环境否则对比基准会被破坏。3.4 给源码打补丁的经验如果你实在要用原始源码包编译大概率会遇到两个经典错误这里提前给出来方便排查第一个是wait.h头文件冲突原始源码里自带了一个旧版的wait.h会和系统中的sys/wait.h产生类型重定义冲突。解决办法是删除源码目录下的src/wait.h文件并修改src/Makefile里的依赖规则把wait.h从头文件依赖列表里去掉。第二个是timeval结构体重复定义这是老代码在GCC 10以上的编译器下不兼容的典型表现。修复思路是修改src/time.c文件在包含系统头文件之前加一行宏定义来屏蔽重复声明。手动打补丁比较费时间所以我个人更建议直接用社区维护的版本把精力花在跑分本身而不是折腾编译上。4. 精准跑分的完整实操四步走做出可信数据4.1 第一步跑分前的系统状态校准进入正式跑分前系统状态必须先“净化”一遍否则数据没有参考价值。先看系统负载。执行top或uptime确认当前load average接近0CPU使用率里没有异常的常驻进程。我遇到过最典型的情况是服务器上有定时备份任务在跑恰好在我执行UnixBench时启动直接把多核分数拉低了15%。跑分前最好把cron任务全部暂停或者挑一个业务低峰期来跑。再看CPU频率。现代服务器CPU都有动态调频机制空闲时降到1GHz以下负载上来再拉高。跑分时如果频率还没拉满就开始计时前几个测试项的分数会很吃亏。可以通过以下命令把CPU调到性能模式# 查看当前调频策略 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 临时切换到性能模式 echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor需要说明的是scaling_governor是运行时切换重启后失效。如果你用的是带intel_pstate驱动的系统可能还要在启动参数里加上intel_pstatedisable才能看到这个接口。在KOS上实测切换到performance模式后单核分数能比默认的powersave模式高出8%左右。如果你跑分的目的就是验证系统优化效果那么“默认模式分数”和“最高性能模式分数”都值得各跑一次这样才能看到优化空间。最后看内存余量。UnixBench虽然不是内存杀手但在多进程模式下每个测试项都会派生独立进程如果内存被其他业务占得只剩几个GB进程可能在fork阶段就被系统杀死导致分数异常。跑分前建议用free -h确认可用内存在8GB以上。4.2 第二步理解测试参数的选择UnixBench的测试参数其实不多核心就三个-c N指定并行测试的进程数模拟多核并发场景。单核机器跑-c 1双核跑-c 2以此类推。-i N指定每项测试的迭代次数默认是3次。迭代次数越多结果越稳定但耗时越长。-D N跑磁盘测试时并发的目录数。我的建议是单核性能用-c 1跑多核性能用-c [CPU核心数]跑。如果机器核心很多比如16核以上还建议额外加一组-c 8的数据用于对比中负载场景的表现。原因是当并发进程数达到一定程度后系统总分会受限于内存带宽和缓存一致性协议单纯堆核数并不能让分数线性增长反而会出现瓶颈。同时记录-c 1和-c N两组数据才能准确判断系统在低负载和高负载下的不同表现。迭代次数的选择也需要权衡。-i 3是最快的方案十几分钟就能跑完一套但遇到系统抖动时数据可能不太稳定-i 10能把极端值平滑掉不少但耗时会增加到40分钟以上。我个人的习惯是正式测试用-i 5既能控制时间又能保证数据稳定性。这里贴上我常用的三组命令直接抄作业# 单核测试5次迭代 ./Run -c 1 -i 5 # 多核测试以16核为例5次迭代 ./Run -c 16 -i 5 # 中负载测试8进程并发5次迭代 ./Run -c 8 -i 5测试期间机器就不要干别的了SSH连接保持空闲状态不要开top盯着看因为top本身的监控也会隔几秒唤醒一次进程对测试产生微小的干扰。想过没一个只有1%干扰的监控进程在单核测试中就能造成约1%的分数误差对“精准跑分”来说这个误差已经不低了。4.3 第三步测试运行中的现场检查按下回车启动测试后终端里会开始滚动每个测试项的Index值。这个阶段不要彻底离开建议每隔几分钟看一眼输出。我总结的三个高价值观察点分别是前几个测试项的Index是否稳步上升、有没有测试项报错退出、单测项的执行时间是否异常。UnixBench的输出信息量不小注意看dhrystone和whetstone这两项它们分别代表整数运算能力和浮点运算能力是整个测试体系里权重最高的两项花费的时间也最长。如果运行过程中出现某个测试项一直卡着不动超过10分钟没有任何输出多半是文件系统或内存相关操作遇到了问题需要中断排查。在ARM平台上还可能出现一种情况某个与原子操作或内存屏障相关的测试项分数极低但这不一定是系统有bug很可能只是内核里对ARM的某些优化没生效。遇到这种情况我先不急着改内核参数先把整套测试多跑两遍如果ARM平台的测试项持续出现可复现的低分再着手排查。4.4 第四步跑分报告的完整解读测试结束后终端会输出一份按测试项排列的详细报告最后给出一个加权总分。不要只看总分重点看明细里每一项的对比。以我的KOS实测数据为例基于Intel Xeon Gold 6330双路环境测试项单进程分数16进程分数Dhrystone 2 using register variables4256.340987.2Double-Precision Whetstone2108.519032.8Execl Throughput1885.712036.4File Copy 1024 bufsize 2000 maxblocks1426.38105.9Pipe Throughput2419.617630.5Pipe-based Context Switching1023.46528.1Process Creation3156.818620.4Shell Scripts (1 concurrent)3870.230152.7Shell Scripts (8 concurrent)4520.528974.1System Call Overhead2031.614834.8你注意到一个现象没有除Shell Scripts外16进程分数基本都是单进程分数的8到10倍左右而不是理想的16倍。这非常正常因为内存带宽、缓存一致性协议和系统总线会成为并发扩展的瓶颈。如果某个测试项的16进程扩展比低于6倍那说明系统在并发场景下可能存在调度或锁竞争问题值得进一步做性能剖析。报告里还会给出每个Index值的对比基准这个“对比基准”是基于一台早期的SPARC工作站完全不用关心绝对值只需要关注分数在不同测试项之间的相对关系和总分在同配置下的横向对比即可。5. 结果调优与常见问题排查跑分之外的实战收益5.1 分数不理想时先查这几个方向我见过很多人在KOS上跑出低分后第一反应是换内核参数比如调整sched_autogroup_enabled、修改HugePages配置。但在瞎调之前先按下面的顺序排查第一查编译器版本。用gcc -O2和gcc -O0编译出来的UnixBench在Dhrystone测试项上可以差出30%以上。很多人从网上下载的二进制包是用-O0编的跑分自然会低。确保自己编译时用的是默认优化级别不要在Makefile里手动降低优化选项。第二查CPU频率锁定。跑分过程中随时查看实时频率watch -n 1 cat /proc/cpuinfo | grep MHz。如果发现频率在测试过程中频繁波动说明调频策略还在干预回4.1节把governor切到performance再跑。第三查NUMA拓扑影响。在双路服务器上如果UnixBench的并发进程全部被调度到同一个NUMA节点另一半CPU的内存带宽就被浪费了。可以用numactl --hardware查看节点拓扑用numactl --interleaveall启动测试来获得更均衡的内存访问模式。我在KOS上实测过双路机器用interleave模式跑-c 32总分能提升5%左右。不要小看这5%在竞品对比时足以拉开一个档次。第四查磁盘性能瓶颈。File Copy测试项直接依赖磁盘I/O如果系统盘是机械硬盘或者共享存储这个分数会成为明显的拖累项。判断方法很简单——单独执行dd if/dev/zero of/tmp/test bs1M count2048看写入速度如果低于200MB/sFile Copy的低分就是磁盘问题而不是系统问题。可以加-D 8参数提高目录并发数或者直接把测试目录放到内存盘里# 把UnixBench目录复制到内存盘运行 sudo mkdir -p /tmp/bench sudo mount -t tmpfs -o size4G tmpfs /tmp/bench cp -r /path/to/Byte-UnixBench-5.1.3 /tmp/bench/ cd /tmp/bench/Byte-UnixBench-5.1.3 ./Run -c 1 -i 5这样File Copy测试就变成了纯内存操作剥离了真实磁盘的影响能看清其他子项的真实性能表现。如果跑分目的是验证CPU和内存性能这个做法非常推荐。5.2 UnixBench在KOS上的两个已知兼容性表现KOS虽然是国产发行版但因为它本身对RHEL生态做了兼容所以大多数在RHEL系上能跑的程序在KOS上都能正常跑。UnixBench也是如此。我遇到并解决过的两个兼容性问题如下。第一个是System Call Overhead测试项在部分KOS内核版本主要是内核5.10版本早期修订号上的分数波动异常显著。同一次测试里连续跑多次结果差异能到15%以上。排查后发现是KOS默认开启了某种审计日志功能每次系统调用都会触发审计钩子带来了额外开销。如果遇到这个问题可以临时关闭审计服务再跑sudo systemctl stop auditd sudo systemctl disable auditd注意生产环境不建议永久关闭auditd跑分结束后记得恢复。第二个是容器环境下跑UnixBench会提示Cannot allocate memory。这是因为容器的内存限制导致UnixBench在fork多进程时超过了cgroup限额。解决办法是给容器分配更高的内存上限或者在容器外跑。在Kubernetes Pod里跑的话可以把limits.memory临时调高到8Gi以上再执行测试。5.3 让跑分数据更有说服力多轮取优策略单次跑完出结果后建议别急着拿分数去对比同一参数多跑几轮。系统级的微小波动在半导体的热力学效应下是不可避免的包括CPU温度变化导致的频率微调、内存刷新周期和测试进程的相位重合等。我推荐一套简单有效的多轮策略第一轮用于“热身”把CPU拉回高负载状态同时验证测试流程不出错。第二轮和第三轮是正式的数据采集轮分别记录分数。取这两轮的几何平均值作为最终报告值或者直接取最大值亦可前提是两轮值差距不超过3%。如果两轮结果差距超过10%不要取平均回到5.1节排查是哪个子系统在波动。我自己统计过在温度控制良好的机房环境里连续三轮UnixBench的总分波动通常在2%以内。超过这个范围系统里一定有什么东西在捣鬼找到它比多跑几轮更有效。5.4 结果沉淀生成可持续对比的基线报告跑分结果不能只是记在脑瓜里。我建议每次跑完把报告重定向保存下来最好带上测试环境的元信息./Run -c 1 -i 5 | tee /tmp/unixbench_c1_$(date %Y%m%d).log然后把系统版本信息一并记录cat /etc/kos-release uname -a lscpu | head -20 free -h gcc --version | head -1我习惯把这些信息保存在同一个文本文件里文件名遵循“KOS版本CPU型号测试参数日期”的规则。这样一个月后再跑一次对比两个文件的分数差异就能判断系统更新或配置变更带来的真实性能影响。注意/etc/kos-release这个路径在KOS上是存在的如果你的环境里没有用cat /etc/os-release也能拿到关键信息。6. 常见问题速查表把这几轮实操里最容易遇到的坑整理成一张表方便你跑分时快速对照判断现象可能原因处理办法wait.h: No such file or directory编译报错使用原始源码包旧头文件冲突换Byte-UnixBench版本或删除源码自带的wait.h运行时报Cannot allocate memory容器内存超限或系统内存不足提高内存限制或关闭无关进程后重跑单核分数远低于同配置其他机器CPU调频策略处于powersave切换到performance模式并锁定频率File Copy分数极低磁盘I/O是瓶颈使用tmpfs内存盘跑测试目录System Call Overhead波动超过15%auditd等安全模块产生额外开销临时停止auditd服务再测试ARM平台部分测试项分数不稳定内核与测试项的适配差异多轮测试求中位数不取单次值编译时time.c报结构体重复定义GCC版本过高旧代码不兼容用社区维护版源码或手动加宏屏蔽测试中途进程被杀物理内存不足导致fork失败用free -h确认余量关闭大内存应用出现问题时先对照这张表定位方向不要盲目修改内核参数。我在实际测试里见过有人因为先改了HugePages配置再跑分结果分数反而下降最后排查了两小时才发现是透明大页的引入增加了内存分配延迟。跑分环境越接近纯净状态问题越容易定位。7. 我对跑分这件事的几点个人体会在KOS上反复折腾UnixBench这段时间我最大的体会是跑分不是目的理解系统才是目的。一份精准的UnixBench报告能告诉你的不只是“这台机器有多快”更是“这台机器在哪些子系统上还有提升空间”。比如我在对比中发现的文件复制性能短板后来排查出是默认I/O调度器在生产环境中没有切换到更适合NVMe的none模式CPU上下文切换分数的波动追踪到是和内核的cgroup调度配置有关。这些发现的价值比跑分本身大得多。最后再分享一个小技巧跑分前先在KOS上执行一遍sync echo 3 | sudo tee /proc/sys/vm/drop_caches把文件缓存清干净。这能让File Copy测试从一开始就在相对干净的缓存状态下运行避免前一分钟刚访问过的数据让某个测试项虚高。这个小动作做不做有时候能让磁盘相关测试项的差距达到8%以上。所有细节都照顾到位了你拿到的跑分报告才真正经得起同行推敲。