当前位置：首页 > news >正文

从/dev/shm到编译优化：保姆级实战记录，我把UnixBench分数提升了XX%

news 2026/4/28 15:28:47

从/dev/shm到编译优化：保姆级实战记录，我把UnixBench分数提升了47%

那天凌晨三点，我的阿里云CentOS 7.9服务器还在嗡嗡作响。屏幕上UnixBench的测试结果刺痛了我的眼睛——单核分数只有1024，这完全配不上这台8核32G配置的机器。作为一名有强迫症的系统工程师，我决定开启一场从内存磁盘到编译器优化的全面性能调优之旅。

1. 环境准备与基准测试

1.1 测试环境搭建

工欲善其事，必先利其器。我选择了一台干净的CentOS 7.9云服务器作为测试平台：

# 系统信息确认 cat /etc/redhat-release # CentOS Linux release 7.9.2009 lscpu | grep "Model name" # Intel Xeon Platinum 8269CY @ 2.50GHz free -h # 32G内存

安装UnixBench的过程看似简单却暗藏玄机：

yum install -y git make gcc libX11-devel libXext-devel git clone https://github.com/kdlucas/byte-unixbench cd byte-unixbench/UnixBench make clean && make

注意：如果遇到fatal error: GL/gl.h: No such file or directory，需要安装mesa-libGL-devel，但图形测试不是本次重点，可以先跳过。

1.2 初始基准测试

首次运行测试的命令和结果：

./Run -c 1 # 单核测试 ./Run -c 8 # 多核测试

原始测试数据对比表：

测试类型	单核分数	8核分数	预期值参考
Dhrystone	3.8M/s	28.1M/s	5M+/单核
Whetstone	1.2M/s	9.3M/s	2M+/单核
文件拷贝	1.5MB/s	10.2MB/s	-
总分	1024	6542	-

问题立刻显现：Dhrystone和Whetstone分数明显低于同级别硬件水平，文件IO性能更是惨不忍睹。

2. 内存磁盘优化实战

2.1 /dev/shm的神奇效果

在分析Run脚本时，我发现所有文件操作测试都依赖TMPDIR环境变量。默认使用/tmp意味着测试受制于磁盘IO性能。而Linux有个神奇的内存盘——/dev/shm。

# 设置临时目录到内存盘 export UB_TMPDIR=/dev/shm # 验证设置生效 grep -r "TMPDIR" ./Run # 确认脚本中使用UB_TMPDIR

优化前后文件测试对比：

测试项	原始分数	/dev/shm优化后	提升幅度
File Copy 1024	1500	9800	553%
File Copy 256	1200	8600	617%
File Copy 4096	1800	10500	483%

踩坑记录：第一次测试时忘记给/dev/shm足够权限，导致测试失败。解决方法：
chmod 1777 /dev/shm

2.2 tmpfs的进阶用法

虽然/dev/shm有效，但我想尝试更彻底的方案——将整个UnixBench放在tmpfs中运行：

# 创建并挂载专用tmpfs mkdir /mnt/unixbench_tmp mount -t tmpfs -o size=2G tmpfs /mnt/unixbench_tmp # 迁移测试环境 cp -r byte-unixbench /mnt/unixbench_tmp/ cd /mnt/unixbench_tmp/byte-unixbench/UnixBench

效果对比表：

优化方案	Dhrystone	Whetstone	文件测试	总分
原始	3.8M	1.2M	1.5MB/s	1024
仅UB_TMPDIR	3.8M	1.2M	9.8MB/s	1850
全tmpfs	4.1M	1.3M	12.4MB/s	2100

有趣的是，不仅文件操作提升，CPU测试也有小幅改善，这说明磁盘IO的减少确实降低了系统整体负载。

3. 编译优化深度调优

3.1 编译器选项的魔法

默认的Makefile使用-O2优化级别，这显然不够激进。我决定打开编译器优化的潘多拉魔盒：

# 修改Makefile关键参数 - CFLAGS = -O2 -fomit-frame-pointer -fno-strict-aliasing -Wall + CFLAGS = -O3 -march=native -flto -fomit-frame-pointer -fno-strict-aliasing -Wall -static

各优化参数解析：

-O3：启用所有优化，包括昂贵的循环展开和向量化
-march=native：针对当前CPU指令集优化
-flto：链接时优化，跨文件分析
-static：静态链接避免动态库开销

优化效果对比：

优化级别	Dhrystone	提升	Whetstone	提升
-O2	4.1M	-	1.3M	-
-O3	5.7M	39%	1.8M	38%
全套优化	6.9M	68%	2.1M	62%

3.2 多线程优化技巧

默认的UnixBench最多测试CPU核数相同的并发数。对于云服务器，我们可以更激进：

# 修改Run脚本中的maxCopies 'system' => { 'name' => "System Benchmarks", 'maxCopies' => 64 }

测试时使用：

./Run -c 64

并发测试结果：

并发数	总分	单任务平均分	CPU利用率
8	6542	817	780%
16	11200	700	1500%
32	18400	575	2900%
64	21500	336	3200%

经验分享：超过物理核心数2-4倍的并发能最大化吞吐量，但单任务性能会下降，需要根据场景权衡。

4. 系统级综合调优

4.1 内核参数微调

通过perf工具分析发现系统调用开销较大，于是调整内核参数：

# 减少上下文切换开销 echo 1 > /proc/sys/kernel/sched_child_runs_first echo 1000000 > /proc/sys/kernel/sched_latency_ns # 提高内存分配效率 sysctl -w vm.overcommit_memory=1 sysctl -w vm.swappiness=10

优化效果：

参数	系统调用开销(us)	进程创建(次/秒)
默认	0.42	5800
优化后	0.31	7200

4.2 环境隔离方案

为确保测试纯净度，我最后采用了cgroup隔离：

# 创建专用cgroup cgcreate -g cpu,memory:unixbench echo "100000" > /sys/fs/cgroup/cpu/unixbench/cpu.cfs_period_us echo "80000" > /sys/fs/cgroup/cpu/unixbench/cpu.cfs_quota_us echo "30G" > /sys/fs/cgroup/memory/unixbench/memory.limit_in_bytes # 在cgroup中运行测试 cgexec -g cpu,memory:unixbench ./Run -c 64