基于RedHatEnterpriseLinux V7(RHEL7)下SPEC CPU 2006环境搭建以及测试流程(之三)——OS调试过程,
基于RedHatEnterpriseLinux V7(RHEL7)下SPEC CPU 2006环境搭建以及测试流程(之三)——OS调试过程,
继续SPECCPU测试记录,本文主要在前两篇文章基础上进行操作系统层面的调优来提高最终的得分,欢迎各位提供意见。
五、OS调优过程
1、tmpfs
介绍tmpfs情况
首先由于时间问题,没有进行完整的tmpfs测试,只是选择比较有代表性的几个bench同时包括int和fp,测试结果如下所示:
int测试tmpfs的四个bench结果
int |
xfs |
tmpfs |
401 |
1710 |
1690 |
458 |
2680 |
2670 |
400 |
2840 |
2840 |
403 |
2310 |
2390 |
???????????????????? fp 测试tmpfs的四个bench结果
bench |
xfs |
tmpfs |
447 |
4850 |
4860 |
459 |
1010 |
1010 |
470 |
2040 |
2040 |
453 |
4310 |
4240 |
465 |
2710 |
2710 |
由上两个表可见,tmpfs有升高有降低,因此为了进一步验证tmpfs对于整体的影响,所以整组bench一起测试完来验证tmpfs下测试情况概述。
?
int的代号 |
bench名称 |
xfs |
tmpfs |
400 |
perbench |
2840 |
2850 |
401 |
bzip2 |
1710 |
1700 |
403 |
gcc |
2310 |
2380 |
429 |
mcf |
4010 |
3840 |
445 |
gobmk |
2570 |
2590 |
456 |
hmmer |
4980 |
4970 |
458 |
sjeng |
2680 |
2670 |
462 |
libquantum |
37900 |
37900 |
464 |
h264ref |
4670 |
4790 |
471 |
omnetpp |
1420 |
1430 |
473 |
astar |
1880 |
1880 |
483 |
xalancbmk |
3390 |
3410 |
结果 |
? |
3410 |
3420 |
?
为了让显示更加可比较,因此将462的结果37900设置成3790。如图和表中所示,tmpfs下有6个结果上升了,2个结果保持一致,有4个稍微降低了,最终结果有所提升。
结论:针对int结果显示,tmpfs对于结果有所提升。
2、sysctl(sched_latency_ns、max)
经过分析,系统的内核参数可能对于最终结果有所影响,因此首先通过对比redhat和Neokylin操作系统默认的内核参数的区别。因此找到不同的几项参数
1)kernel.sched_latency_ns
内核调度延迟时间,默认为24000000ns,修改为12000000ns,并进行测试。
修改方法:#sysctl kernel.sched_latency_ns=12000000即可。
由于时间有限,选择一个bench403进行比较。
?
? |
默认 |
latency_ns=12000000 |
403 |
2310 |
2310 |
?
上述结果为设置与否没有影响,但是不能下结论说这个参数一定没有影响,等待后续时间充裕的情况下,测试整组bench来完整的验证此参数的影响;
2)MALLOC_AREAN_MAX
该环境变量影响内存分配问题,新版本glibc(2.11)为了提升内存分配性能,每个线程分配了内存池,64位操作系统默认是64M,可以通过这个变量进行修改。
通过export MALLOC_ARENA_MAX值来进行测试,测试结果如下所示:
?
MALLOC_ARENA_MAX |
未设置 |
未设置 |
2 |
4 |
filesystem |
xfs |
tmpfs |
tmpfs |
xfs |
401 |
1710 |
1690 |
1700 |
1690 |
458 |
2680 |
2670 |
2670 |
2670 |
400 |
2840 |
2840 |
2830 |
2840 |
403 |
2310 |
2390 |
2380 |
2310 |
上述结果中可见,当将参数设置为2时,此时和相同文件系统tmpfs相比,2个下降,1个未变一个升高。由此可见,对于将MALLOC_ARENA_MAX设置为2时,有可能提高最终结果,需要在时间允许的情况下进行完整的bench测试。xfs文件系统情况下,将MALLOC_ARENA_MAX设置为4时,结果2个下降2个不变,基本可以判定xfs下修改此参数为4结果不好,以后设置时可以放弃。
如上表所示,只是设置了2和4两个值,还有多个值没有尝试。因此,在时间允许的情况下,可以进行更多的测试来验证此值是否有影响。
结论:tmpfs下将MALLOC_ARENA_MAX修改为4可能提高最终结果,未来时间可以进行完整性测试。
3、更换三星内存
经过多次测试以及Intel给的建议,本次实验中进行三星内存的测试,最终发现针对这款主板下,海力士的内存更加合适。
原本内存:64*16G,海力士内存2Rank,容量1TB,频率
更改内存:64*32G,三星内存2Rank,容量2TB,频率
?
结果显示10个下降,1个不变,1个上升,最终结果降低20分,3390。由此可见,三星内存的效果没有原来海力士16GB结果好。同时为了进一步验证此内存的问题,我们利用stream工具来测试内存的吞吐量。海力士测试的吞吐量为258GB/s,而三星的内存吞吐率下降了4GB/s,在254GB/s左右。
结论:目前来看三星内存针对当前的主板,其效果不如海力士的好。由此测试发现,针对SPECCPU来说,CPU占据最主要地位,而内存影响较小。同时,针对内存插法、BIOS中memory interleave设置等相关设置均有待继续研究。同一个channel,三个插槽情况下,插入的内存条数越多则会降频。因此,大部分人选择将三个插槽中插入两个,以达到容量和频率的平衡。
4、尝试tuned-profile,latency-performance、throughput-performance
系统自带的tuned模式有多种,现在系统自带的有如下模式:
#tuned-adm list
Available profiles:
- balanced
- desktop
- latency-performance
- network-latency
- network-throughput
- powersave
- throughput-performance
- virtual-guest
- virtual-host
Current active profile:throughput-performance
经过分析其中latency-performance也是对于低延时高效率的计算而用的模式,因此修改模式为latency-performance模式进行测试。修改办法:
#tuned-adm? profile latency-performance
再利用tuned-adm active查看是否设置成功。设置完成后利用一个bench进行测试,测试结果:
?
5、动态无时钟
默认情况下,红帽企业版 Linux 7 使用无时钟内核,它不会中断空闲 CPU 来减少用电量,并允许较新的处理器利用深睡眠状态。
红帽企业版 Linux 7 同样提供一种动态的无时钟设置(默认禁用),这对于延迟敏感型的工作负载来说是很有帮助的,例如高性能计算或实时计算。要启用特定内核中的动态无时钟性能,在内核命令行中用 nohz_full 参数进行设定。在 16 核的系统中,设定 nohz_full=1-15 可以在 1 到 15 内核中启用动态无时钟内核性能,并将所有的计时移动至唯一未设定的内核中(0 内核)。这种性能可以在启动时暂时启用,也可以在 /etc/default/grub 文件中永久启用。要持续此性能,请运行 grub2-mkconfig -o /boot/grub2/grub.cfg 指令来保存配置。
启用动态无时钟性能需要一些手动管理。
当系统启动时,必须手动将 rcu 线程移动至对延迟不敏感的内核,这种情况下为 0 内核。
# for i in `pgrep rcu` ; do taskset -pc 0$i ; done
? 在内核命令行上使用 isolcpus 参数来将特定的内核与用户空间任务隔离开。
? 可以选择性地为辅助性内核设置内核回写式 bdi-flush 线程的 CPU 关联:
echo 1 > /sys/bus/workqueue/devices/writeback/cpumask
验证动态无时钟配置是否正常运行,执行以下命令,其中 stress 是在 CPU 中运行 1 秒的程序。
# perf stat -C 1 -eirq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
可替代 stress 的是一个脚本,该脚本的运行类似 while :; do d=1; done 。以下链接中的程序是另一个合适的替代程序: https://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/stress.html。
默认的内核计时器配置在繁忙 CPU 中显示 1000 次滴答记号:
# perf stat -C 1-e irq_vectors:local_timer_entry taskset -c 1 stress -t 1 -c 1
1000 irq_vectors:local_timer_entry
动态无时钟内核配置下,用户只会看到一次滴答记号:
# perf stat -C 1 -e irq_vectors:local_timer_entrytaskset -c 1 stress-t 1 -c 1
1irq_vectors:local_timer_entry
虽然提到它可以提高高性能计算,但是由于在实际运行脚本中我们已经设定了numa绑定策略,这个与设置动态无时钟的numa策略有冲突。因此,最终不能完成测试。
结论:滴答消耗只给CPU0,其他的CPU不进行时钟滴答操作。理论上会有所提高,但是我们测试时rate的数量和内核数量一致,而此时利用taskset将时钟滴答集中在CPU0上,所以数量肯定不够,导致最终不能运行。如果测试中没有使用到所有的core绑定,那么则可以使用此性能来提高性能。
?
6、cpuscaling模式governor:performance、powersave
这个为CPU扩展的模式,默认系统应该会选择性能优化:performance。利用cpupower工具来查看当前的governor
#cpupower -c all frequency-info
部分结果如下所示
?current policy: frequency should be within 800MHz and 3.20 GHz.
????????????????? The governor "performance"may decide which speed to use
????????????????? within this range.
在正式测试之前需要检查这个模式是否为performance,如果不是则需要利用
#cpupower -c all set-frequency -gperformance
来设置
7、irqbalance
9、默认numad服务开启与否以及利用numad 命令
10、numa绑定策略
11、I/O策略以及参数(nr_requests、read_ahead_kb)[speccpu.txt]
评论暂时关闭