【Anolis 8.8 龙蜥OS】手把手教你用unixbench做CPU性能测试,零基础入门到精通
选用开源性能测试工具 UnixBench 对目标虚拟机进行基准测评。作为一款经典的 Unix/Linux 系统综合性能评估工具,UnixBench 广泛应用于 VPS 性能对比。其测试维度覆盖 2D/3D 图形处理、系统调用及进程调度等多个方面,评估结果受硬件配置、操作系统版本及编译环境等多重因素影响。该工具通过将各项实测数据与参考基线进行对比生成索引值,最终得分具有横向可比性,能够客观反映不同
文章目录
一、概述
选用开源性能测试工具 UnixBench 对目标虚拟机进行基准测评。作为一款经典的 Unix/Linux 系统综合性能评估工具,UnixBench 广泛应用于 VPS 性能对比。其测试维度覆盖 2D/3D 图形处理、系统调用及进程调度等多个方面,评估结果受硬件配置、操作系统版本及编译环境等多重因素影响。该工具通过将各项实测数据与参考基线进行对比生成索引值,最终得分具有横向可比性,能够客观反映不同硬件配置或内核参数下的性能差异。
二、下载地址

三、安装准备
3.1 操作环境
操作系统版本:Anolis OS 8.8(5.10.134-16.1.an8.aarch64)
测试架构:arm,16核32G虚拟机

3.2 软件版本
Unixbench 6.0.0
3.3 编译安装
- UnixBench 采用 GNU 源码分发,部署前需经历本地编译构建流程。为确保编译顺利,请提前安装以下前置依赖环境:
# 以 CentOS / Rocky / AlmaLinux 为例
yum install -y gcc gcc-c++ make libX11-devel libXt-devel libXext-devel libXaw-devel mesa-libGL-devel libtool perl-Time-HiRes autoconf
# 以 Ubuntu / Debian 为例
apt-get install -y build-essential libx11-dev libxt-dev libxext-dev libxaw7-dev libgl1-mesa-dev
编译结果
🚨 常见编译报错 Fix
如果在 make过程中出现以下错误,说明缺少依赖:
-
报错: cannot find -lX11
解决: 安装了 libX11-devel(CentOS) 或 libx11-dev(Ubuntu)。 -
报错: glx.h: No such file or directory
解决: 安装了 mesa-libGL-devel(CentOS) 或 libgl1-mesa-dev(Ubuntu)。
解压软件
tar -zxvf byte-unixbench-6.0.0.tar.gz

四、执行测试
进入 UnixBench 源码根目录,直接执行 Run脚本即可启动测试:
cd /root/byte-unixbench-6.0.0/UnixBench
./Run –c 1 –c 4 -c 8
# 记录测试结果,包括单进程和多进程下的处理能力
如果没有编译环境,直接执行会报错
📊 测试模式与耗时
该工具默认会自动执行两种基准模式,这也是我们评估系统性能的核心维度:
单线程
- 模式 (Single Copy): 模拟单核/单进程下的性能表现。
- 满并发模式 (Multi Copy): 根据 CPU 核心数(需配合 -c参数或默认逻辑)跑满系统负载,测试多核吞吐量。
注意: 这是一个长时间的压力测试(通常持续数十分钟)。测试过程中,各项指标会实时打印在终端上,请耐心等待直至完成。
📁 结果获取与分析
测试结束后,详细的日志与汇总报告会自动归档至根目录下的 results/文件夹中。我们主要关注以下两个层面的数据:
- 核心指标(定性分析):重点关注最终的 Index Score(指数得分)。
- 单核分数: 反映系统的基础运算能力(如系统调用、内存延迟)。
- 多核分数: 反映系统的并行处理能力。
这些数据是判定性能优劣的直接量化凭证。
- 子项拆解(定位分析):当进行版本回归测试或系统调优对比时(例如:版本 V1 升级至 V2 后,跑分出现明显下滑),仅靠总分往往不够,需要深入 results目录下的详细日志:
- 方法: 逐项对比各子测试项的得分(如 Pipe-based Context Switching、System Call Overhead、2D graphics等)。
- 目的: 识别出劣化严重的子项(例如发现“上下文切换”性能暴跌),从而将排查方向精准锁定在特定的内核模块或系统配置上(如调度器策略、CPU 频率调节等)。
💡 避坑提示:
如果发现多核分数并不是单核分数的线性倍数(例如 100 核机器分数不到单核的 50 倍),请不要惊讶。这是因为 UnixBench 中的某些测试项(如 Pipe、Process Creation)受限于系统锁竞争和调度开销,在多核环境下会出现边际效应递减,这属于正常现象。
五、测试结果
至此,UnixBench 已完成部署。工具基于 2核4G(2C4M)的标准参考基线(Reference Machine) 进行计算,通过标准化算法对各子项加权计算得出最终指数。得分与系统性能呈正相关(数值越高越优)。具体的执行流程与结果数据如下图所示。
UnixBench 的 -c 参数是控制并发副本数,不是控制 CPU 核心数。在 16C 机器上:
./Run -c 1 # 单核基准(1个进程)
./Run -c 2 # 2进程并发
./Run -c 4 # 4进程并发
./Run -c 8 # 8进程并发
./Run -c 16 # 16进程并发
16C 机器全部核心都能调度开,跑完直接出 5 档数据,横跨 1核到16核的Scaling曲线,结论最干净——单台机器排除了硬件差异。
逐个跑(方便看日志)或者一行批量(无交互,安静等结果):
for c in 1 2 4 8 16; do ./Run -c $c; done
5.1 ./Run -c 1 单核基准【1进程并发测试结果】为例




六、注意事项
作为最基准的测试套件,unixbench不同版本可能测出来的数据会有所不同,只要是同一版本测试,数据可认为是真实的,对于多核服务器,unixbench测试多核性能的时候,需要调整Run脚本下的参数,比如被测服务器是100核的,那么Run文件中需要将-C后的数字改成100,否则多核场景跑不起来
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
所有评论(0)