unixbench跑分出错，多数情况不是服务器性能问题，而是编译环境、CPU频率策略和进程设置没调对，把这三个方面处理好，跑分结果才能作为参考，我这次实测了两台不同配置的机器，把踩过的坑和解决步骤完整记录下来。
UnixBench编译失败？先解决基础依赖问题
第一次跑unixbench是在一台酷番云轻量服务器上,系统是Debian 11，下载源码后直接执行make，结果报了一堆错，最常见的是找不到malloc.h或者sys/sysinfo.h，网上查了一圈，其实是缺了libc6-dev这个基础包。
- 用
apt-get install libc6-dev gcc make先装编译工具链，四核机器建议加-j4参数并行编译，能快不少 - 装完之后重新make,通常就能通过
- 如果还报错,检查一下是不是用了32位系统，unixbench对32位环境的兼容性明显不如64位
编译通过后运行./Run，又遇到个新问题：单个测试跑完了，但整个流程需要二十多分钟，中途容易因为SSH断开导致测试中断，解决方案是配合screen或tmux使用，把任务放到后台会话里，断开连接也能继续跑。
unixbench跑分不准？先关掉CPU省电模式和动态调频
这是最影响跑分结果的一个坑,我一开始在一台独立服务器上跑，单核分数只有1200多分，而同样型号的CPU在别人评测里能跑到1600分，排查后发现是CPU调频策略的问题。
- 查看当前CPU频率策略：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor - 如果输出是
powersave，跑分会被压得很惨 - 临时切换到
performance模式：echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor -
每个核心都要设置一遍,可以用
for i in {0..N}循环批量处理
切换后重新跑unixbench,分数直接提升了30%以上，行业共识认为，跑分前不检查CPU调频模式，测出来的数据基本没有参考意义。
另外一个容易忽略的问题：测试时后台还跑着其他进程，比如宝塔面板的监控、Docker容器之类的，我用htop看了一下，发现有个日志采集程序占了25%的CPU，这跑出来的分数肯定偏低。
UnixBench单核多核怎么看？先搞懂测试逻辑再下结论
跑完unixbench会生成一个报告,里面包含各个单项的分数和总分，很多新手纠结单核和多核数据怎么参考，这里需要明确一点：unixbench自带的多线程测试，会把负载平均分配到所有核心上。
- 单核性能看默认的
Dhrystone 2、Whetstone、Execl Throughput这几个跑分 - 多核性能看
Pipe-based Context Switching和Process Creation的分数，这两个项目能反映核间通信和进程调度的效率 - 总分会根据核心数自动调整,四核和八核机器的总分直接比较没有意义，得看每核心得分
以我的实测为例,一台8核16线程的机器，总分跑出了6800多分，看起来比另一台4核机器的3200分高一倍，但单核得分两者其实是同一水平（约1500分左右），所以如果你想判断两台服务器哪个更适合高频交易或单线程应用，重点看单核得分。
UnixBench和GeekBench对比：服务器场景下谁更可信
unixbench跑分结果不稳定,有人会问是不是该用Geekbench之类的工具替代，我两台机器都跑了一遍，结论是：场景不同，工具侧重点就不同，谈不上谁替代谁。
| 对比项 | UnixBench | Geekbench |
|---|---|---|
| 测试侧重点 | 类Unix系统系统级综合性能 | CPU单核多核算力为主 |
| 适用系统 | Linux/Unix服务器 | 桌面、移动端、跨平台 |
| 测试方式 | 多进程模拟真实任务 | 单项算法基准测试 |
| 分数参考价值 | 服务器并发能力直接参考 | 算力对比更直观 |
我实际测了下,同一台机器Geekbench 6单核分数1100分，多核7800分，看上去挺正常；但unixbench的File Copy项目测出来只有400多分，明显偏低，后来发现是云盘的IOPS限制影响了成绩，但Geekbench根本测不出这个瓶颈，所以Linux服务器真实负载场景，unixbench更有参考价值。
跑分结果不稳定的另一个隐藏因素：虚拟化层和内核参数
在云服务器上跑unixbench,虚拟化类型对分数据统计影响也不小，我试过在同一台物理机上开KVM虚拟机和OpenVZ容器，跑出来的结果差了近两倍，主要是CPU调度和内存访问延迟差异导致的。
- 用
lscpu查看Hypervisor vendor，如果是KVM或Xen，分数相对接近物理机 - 如果是OpenVZ或LXC容器,进程创建和上下文切换的分数通常会明显偏低
- 查看内核参数：
cat /proc/sys/kernel/pid_max，默认32768在一些高并发测试下会不够用
另外说一个小技巧：如果把进程数参数设置得太高，比如四核机器直接./Run -c 16，不仅耗时翻倍，还容易触发OOM，我用一台2G内存的小机器试过，跑到一半进程就被系统kill掉了，日志显示Out of memory
。
跑分前的环境准备清单（总结版）
在跑unixbench之前,按下面的顺序检查一遍，能省掉不少麻烦：
- 系统版本：建议64位Linux，内核版本不低于4.x，旧内核在多核调度上有劣势
- 编译环境：装好gcc、make、libc6-dev，缺哪个补哪个
- CPU策略：切换到performance模式，关掉动态调频
- 进程环境：停掉监控程序、备份任务等无关进程
- 虚拟化确认：确认是KVM还是容器，容器跑分偏低是正常现象
- 内存评估：至少给每个测试进程留500MB内存，小内存机器别贪多核参数
这几项都调好之后,我用酷番云轻量服务器（4核8G）测出来的结果是单核1745分，多核6210分，和官方公布的同配置数据基本在同一个区间，如果是跑在容器里，分数低一些不用太担心，不代表硬件有问题。
常见问题解答
unixbench跑分低怎么办？
先按上面的方法确认CPU调频模式是performance,然后检查后台是否有占用资源的进程，排除这两项后分数仍然低，再看虚拟化类型，容器环境下建议用宿主机性能作为参考基准。
unixbench测试中途卡住怎么处理？
常见原因是文件拷贝测试的临时文件目录空间不足,可以用df -h确认/tmp分区可用空间，清空后重试，另外不要用SSH直接跑，配合tmux或nohup避免中断。
unixbench结果文件在哪里？
默认存放在results/目录下，按测试时间戳命名，里面包含index.html格式的详细报告。html文件可以直接下载到本地，用浏览器打开查看各项明细，比看命令行输出直观得多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641108.html
