0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

原因分析:CPU拓扑差异导致Unixbench分数异常

Linux阅码场 来源:未知 作者:李倩 2018-07-06 09:35 次阅读

本文通过实验论证:Unixbench的Pipe-based Context Switching用例受操作系统调度算法的影响波动很大,甚至出现了虚拟机跑分超过物理机的情况。在云计算时代,当前的Unixbench已不能真实地反映被测系统的真实性能,需要针对多核服务器和云计算环境进行完善。

简单的说,视操作系统多核负载均衡策略的差异,该用例可能表现出两种截然不同的效果:

1、在惰性的调度策略环境下,测试得分较高,但是会导致系统中任务调度延迟,最终可能引起业务性能抖动。例如,在视频播放、音频处理的业务环境中,引起视频卡顿、音频视频不同步等问题。

2、在积极的调度策略环境下,测试得分偏低,但是系统中任务运行实时性更高,业务运行更流畅。

后文将详细说明Pipe-basedContext Switching用例的设计原理,测试其在不同系统中的运行结果,并提出测试用例改进建议。

1测试背景

近期,团队在进行服务器选型的时候,需要对两款服务器进行性能评估,其中一款服务器采用64核Xeon CPU,另一台则采用16核Atom CPU。详细配置信息如下:

指标名称 Xeon服务器 Atom服务器
Architecture x86_64 x86_64
CPUs 64 16
Threads per core 2 1
Core(s) per socket 16 16
Socket(s) 2 1
NUMA node(s) 1 1
Model name Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz Intel(R) Atom(TM) CPU C3958 @ 2.00GHz
CPU MHz 2499.902 1999.613
BogoMIPS 4993.49 3999.22
L1d cache 32K 24K
L1i cache 32K 32K
L2 cache 256K 2048K
L3 cache 40960K None

根据硬件厂商的评测,Xeon服务器的综合性能是Atom服务器的3倍。

我们采用了久负盛名的Unixbench性能测试套件,为我们最终的选择提供参考。

Xeon的性能碾压Atom是毋庸置疑的,毕竟Atom 更专注于功耗而不是性能,Atom服务器甚至没有3级缓存,并且StoreBuffer、Message Queue的深度更低,流水线级数更少。

出于业务需求,在整个测试过程中我们更关注单核的性能。为了排除软件的影响,两台服务器均安装Centos 7操作系统。

测试命令很简单,在控制台中执行如下命令:

./Run -c 1 -v

执行时间比较久,我们可以到一边去喝点烧酒。一杯烧酒下肚,神清气爽:-)可以看看结果是否符合咱们的预期:

指标名称 Xeon服务器 Atom服务器
Dhrystone 2 using register variables 2610.1 1283.7
Double-Precision Whetstone 651.2 489.4
Execl Throughput 447.9 361.5
File Copy 1024 bufsize 2000 maxblocks 2304.5 955.0
File Copy 256 bufsize 500 maxblocks 1494.5 711.2
File Copy 4096 bufsize 8000 maxblocks 4475.9 1396.2
Pipe Throughput 1310.9 614.4
Pipe-based Context Switching 428.4 339.8
Process Creation 461.7 159.6
Shell Scripts (1 concurrent) 1438.8 326.7
Shell Scripts (8 concurrent) 5354.5 789.8
System Call Overhead 2237.0 930.1
System Benchmarks Index Score 1390.9 588.4

总分整体符合预期:Xeon服务器单核性能是Atom服务器的2.36倍(1390/588.4)

但是,这里出现了一个异常,细心的读者应该已经发现:Pipe-based Context Switching测试用例的结果比较反常!从上表可以看出,无论是总分还是单项分数,Xeon服务器均远远超过Atom服务器。其中也包括Pipe Throughput这项用例。然而“Pipe-based Context Switching”这项指标显得有点与众不同:在这项指标中,Xeon服务器的优势并不明显,仅领先25%左右。

为了排除测试误差,我们反复进行了几次测试,均发现同样的规律。“Pipe-based Context Switching”项的分数差异并不明显,没有体现出Xeon服务器的性能优势。

这一问题引起了我们的兴趣,Unixbench这样的权威测试软件的结果居然和厂商宣称的出入这么大。为了找出原因,我们使用其他测试环境,进行了一系列的对比测试。首先,我们找了更多物理机进行对比分析。

1.1物理机对比测试

为此,我们使用另一组服务器进行对比测试,其型号分别为:HP ProLiantDL360p Gen8、DELL PowerEdge R720xd。配置如下:

指标名称 HP ProLiant DL360p Gen8 DELL PowerEdge R720xd
Architecture x86_64 x86_64
CPUs 24 32
Threads per core 2 2
Core(s) per socket 6 16
Socket(s) 2 2
NUMA node(s) 1 1
Model name Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
CPU MHz 1200.000 2300.000
BogoMIPS 4594.05 4615.83
L1d cache 32K 32K
L1i cache 32K 32K
L2 cache 256K 256K
L3 cache 15360K 20480K

分别在两台服务器的控制台中输入如下命令,单独对“Pipe-based Context Switching”用例进行测试:

./Run index2 -c1

得到该测试项的分数为:

指标名称 ProLiant DL360p Gen8 PowerEdge R720xd
Pipe-based Context Switching 381.4 432.1

测试结果与上面相似,硬件参数明显占优的DELLL跑分仅领先HP不到20%:-(

1.2物理机VS虚拟机

测试似乎陷入了迷途,然而我们一定需要将加西亚的信送到目的地,并且坚信“柳暗花明又一村”的那一刻终究会到来。

为此,我们使用三组云虚拟机来进行测试。这三组虚拟机配置如下:

指标名称 虚拟机A 虚拟机B 虚拟机C
Architecture x86_64 x86_64 x86_64
CPUs 4 4 4
Threads per core 2 1 1
Core(s) per socket 2 4 4
Socket(s) 1 1 1
NUMA node(s) 1 1 1
Model name Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz Intel(R) Xeon(R) CPU E5-26xx v4 Intel(R) Xeon(R) CPU E5-2676 v3 @2.40 GHz
CPU MHz 2494.222 2394.454 2400.102
BogoMIPS 4988.44 4788.90 4800.07
L1d cache 32K 32K 32k
L1i cache 32K 32K 32k
L2 cache 256K 4096K 256K
L3 cache 40960K none 30720K

这三款虚拟机与此前的物理机参数相差不大,如果不出意外的话,分数应当介于300~400之间。

然而测试结果出人意料,以至于笔者的镜片摔了一地:

指标名称 虚拟机A 虚拟机B 虚拟机C
Pipe-based Context Switching 109.4 589.1 105.1

特别令人吃惊的是:第二组虚拟机的测试分数,竟然是物理主机的1.5倍,并且是第一组虚拟机和第三组虚拟机的5.4倍。

1.3单核和多核对比测试

为此,我们认真分析不同系统中的CPU占用率。发现一个特点:在Pipe-based Context Switching用例运行期间,在得分高的环境中,两个context线程基本上运行在同一CPU上。而在得分低的环境中中,两个context线程则更多的运行在不同的CPU上。这说明:测试结果差异可能与Guest OS中的调度算法及CPU负载均衡策略有关。

我们不得不启用了排除法,先看单核和多核之间的差异。

为了验证猜想是否正确,我们临时修改了Guest OS中内核调度算法。修改原理是:在唤醒线程时,不管其他CPU核是否空闲,优先将被唤醒任务调度到当前CPU中运行。这样的调度算法,其缺点是:被唤醒任务将不能立即运行,必须等待当前线程释放CPU后才能获得CPU,这将导致被唤醒线程的实时性较弱。

经过测试,在打上了Linux内核调度补丁的系统中,Pipe-based Context Switching在虚拟机和物理机上,得分大大提升。实际测试的结果如下:

指标名称 虚拟机A
Pipe-based Context Switching 530.2

很显然,我们不能将上述补丁直接应用到生产环境中,因为该补丁会影响任务运行的实时性。因此我们将Linux内核调度补丁回退,并修改“Pipe-based ContextSwitching”测试用例的代码,强制将context线程绑定到CPU 0中运行,这样可以避免Guest OS中的调度算法及CPU负载均衡算法的影响。测试结果如下:

指标名称 虚拟机A 虚拟机B 虚拟机C
Pipe-based Context Switching 761.0 953.7 675.3

我们再次修改“Pipe-based Context Switching”测试用例的代码,强制将context线程分别绑定到CPU 0和CPU 1中运行,这样也可以避免Guest OS中的调度算法及CPU负载均衡算法的影响。测试结果如下:

指标名称 虚拟机A 虚拟机B 虚拟机C
Pipe-based Context Switching 109.1 133.6 105.1

可以看到,应用了新的“Pipe-basedContext Switching”补丁之后,所有测试结果都恢复了正常,离真相越来越近了。

2原因分析: CPU拓扑差异导致Unixbench分数异常

通过前面针对“Pipe-based Context Switching”单实例用例的测试,带给我们如下疑问:

为什么在该用例中,虚拟机B得分接近600,远高于虚拟机A、虚拟机C,甚至高于虚拟机A所在的物理机?

为了分析清楚该问题,我们分析了Pipe-based Context Switching用例, 这个用例的逻辑是:测试用例创建一对线程A/B,并创建一对管道A/B。线程A写管道,线程B读A管道;并且线程B写B管道,线程A程读B管道。两个线程均同步执行。

经过仔细分析,虚拟机A和虚拟机B在该用例上的性能差异的根本原因是:在虚拟机环境下,底层Host OS向Guest OS透传的cpu拓扑不同,导致虚拟机系统中的调度行为不一致, 最终引起很大的性能差异。其中虚拟机A是按照Host主机的实际情况,将真实的CPU拓扑传递给Guest OS。而虚拟机B的主机则没有将真实的物理主机CPU拓扑传递给Guest OS。这会导致虚拟机内所见到的CPU拓扑和共享内存布局有所不同。

在真实的物理服务器上,每个物理核会有各自的FLC和MLC,同一个Core上的CPU共享LLC。这样的CPU拓扑允许同一Core上的CPU之间更积极的进行线程迁移,而不损失缓存热度,并且能够提升线程运行的实时性。这个特性,更利于视频播放这类实时应用场景。

下图是虚拟机A和虚拟机B中看到的CPU视图:

拓扑结构的差异地方在LLC的共享方式,虚拟机A使用的拓扑结构与物理机一致,同一个Core内CPU共享LLC。而虚拟机B的配置是同一个Core内CPU不共享LLC。不共享LLC的场景下,Linux将每个CPU在LLC层次的调度域设置为空。这样,虚拟机B的Guest OS会认为同一物理CPU内的两个超线程是两个独立的CPU,处于不同的域之间(这与实际的物理机配置不一致),因此其负载均衡策略会更保守一些。唤醒一个进程时,内核会为其选择一个运行的目标CPU,linux的调度策略会考虑亲和性(提高cache命中率)和负载均衡。在Linux 3.10这个版本下,内核会优先考虑亲和性,亲和性的目标是优先选取同一个调度域内的CPU。虚拟机A共享LLC,所有的CPU都在同一个调度域内,内核为其选择的是同一调度域内的空闲CPU。而虚拟机B因为LLC层次的调度域为空,在进入亲和性选择时,无法找到同一个调度域内的其它空闲CPU,这样就直接返回了正在进行唤醒操作的当前CPU。

最终,在虚拟机B中,除了偶尔进行的CPU域间负载均衡以外,两个测试线程基本上会一直在同一个CPU上运行。而虚拟机A的两个进程会并发的运行在两个不同的CPU上。

这一特征下的运行时间轴如下:

虚拟机B场景引入的开销是唤醒和等待运行开销,虚拟机A场景引入的开销是唤醒和切换运行开销。

在正常的工作负载下面,进程运行的时间会远大于进程切换的开销,而Pipe-based Context Switching用例模拟的是一个极限场景,一个线程在唤醒对端到进入睡眠之间只执行很简单的操作,实际等待运行的开销远小于切换运行的开销。

此外,在虚拟化场景下,两种方式唤醒操作中也存在差异,在虚拟机A这个场景下,唤醒的开销也远大于虚拟机B场景中的唤醒开销。最终出现虚拟机B上该用例的得分远高于虚拟机A、虚拟机C,甚至高于物理机上的得分。

为了进一步验证我们的分析是否正确。我们在HOST OS中,分别向虚拟机A的GuestOS和虚拟机B的Guest OS按照不同方式传递CPU拓扑。测试发现:在同样的CPU拓扑结构下,二者的测试分数是一致的。换句话说,导致该项测试分数差异的原因,在于不同的HOST OS向Guest OS传递的CPU拓扑存在差异,进而导致Guest OS中任务调度行为的差异。

3 结论:Unixbench需要针对多核服务器和云环境进行优化

unixbench的Pipe-based Context Switching用例受操作系统调度算法的影响比较大。视操作系统多核负载均衡策略的差异,可能表现出两种截然不同的效果:

1、在多核负载均衡策略不积极的系统中,测试线程更多的运行在同一个CPU中,线程之间的切换开销更低。因此测试得分更高,但是会导致系统中任务调度延迟。在实时性要求比较高的系统中,这会引起业务抖动。例如,在视频播放、音频处理的业务环境中,这可能引起视频卡顿、音频视频不同步等问题。

2、在多核负载均衡策略更积极的系统中,测试线程更多的运行在不同的CPU中,线程之间的切换开销更高。因此测试分值更低,但是系统中任务调度延迟更低,业务的性能不容易产生波动。

换句话说:当前的Unixbench已不能真实地反映被测系统的真实性能,需要针对多核服务器和云计算环境进行完善。

4 修改建议

我们建议调整unixbench测试用例,将测试用例的线程绑定到Guest OS的CPU上。这样就可以避免受到Guest OS调度策略和CPU负载均衡策略的影响。具体来说,有两种方法:

1、将context1和context2两个线程绑定在同一个CPU核上面。这样可以反应出被测试系统在单核上的执行性能。

2、将context1和context2两个线程分别绑定到不同CPU核上面。这样可以反应出被测试系统在单核的执行性能,以及多核之间的核间通信性能。

(完)

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • cpu
    cpu
    +关注

    关注

    68

    文章

    10824

    浏览量

    211126
  • 云计算
    +关注

    关注

    39

    文章

    7732

    浏览量

    137188
  • 服务器
    +关注

    关注

    12

    文章

    9017

    浏览量

    85181

原文标题:燕青: Unixbench 测试套件缺陷深度分析

文章出处:【微信号:LinuxDev,微信公众号:Linux阅码场】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    CYT2B7 SFlash被异常修改的原因

    0x17001C00 ~ 0x17006FFF这段区域,芯片处理Normal模式下,是否可被异常篡改呢? 请各位专家帮忙分析下,SFlash被异常修改的可能原因
    发表于 05-28 08:11

    【NanoPi NEO试用体验】利用unixbench进行性能评估

    ,是比较通用的测试VPS性能的工具.UnixBench会执行一系列的测试,包括2D和3D图形系统的性能衡量,测试的结果不仅仅只是CPU,内存,或者磁盘为基准,还取决于硬件,操作系统版本,编译器.测试系统
    发表于 11-10 16:05

    产生Fault异常原因是什么? 如何分析Fault异常

    产生Fault异常原因是什么?如何分析Fault异常
    发表于 11-30 07:59

    导致STM32进入HardFault异常原因

    1、导致异常原因有很多,例如:直接使用未分配空间的指针、栈溢出等异常非法操作便会使程序进入“HardFault”异常状态。接下来在MDK工
    发表于 01-07 06:52

    压缩机异常响声原因分析及处理

    本文通过对压缩机异常响声的原因分析理处理过程的描述.说明了因果分析法用于解决实际生产问题的科学性瑟实效性。
    发表于 05-23 14:12 11次下载

    CPU PG异常检修

    CPU PG异常检修 一、CPU PG信号示例图              
    发表于 04-26 16:29 2365次阅读
    <b class='flag-5'>CPU</b> PG<b class='flag-5'>异常</b>检修

    导致致命异常错误和无效页错误的原因是什么?

    导致致命异常错误和无效页错误的原因是什么? 如果Microsoft Word或Excel“崩溃”,意味着在程序执行过程中出现了严重的错误。操作系统常常会发现存在一个严重问题,并
    发表于 08-05 10:33 1003次阅读

    导致变压器温度异常原因

    导致变压器温度异常原因:    1、内部故障引起温度异常    变压器内部故障如匝间短路或层间短路,线圈对围屏放电,内部引
    发表于 12-05 14:49 1416次阅读

    导致MCU出现功能严重异常的几个原因分析

    我们在从事MCU应用开发过程中,难免会碰到MCU芯片异常的问题。比如异常复位,表现为复位脚有电平跳变或者干脆处于复位电平;在做代码调试跟踪时,发现代码往往进不到用户main()程序;或者时不时感觉芯片死掉了,功能完全不可控等。 针对类似严重
    发表于 11-29 16:10 1.2w次阅读

    CPU 拓扑中的SMP架构

    CPU 拓扑用来表示 CPU 在硬件层面的组合方式,本文主要讲解 CPU 拓扑中的 SMP(Symmetric Multi-Processo
    的头像 发表于 08-29 11:02 4357次阅读

    分享排查Linux系统CPU占用的一个Shell脚本

    众所周知,Linux系统CPU占用100%这个异常现象还是经常遇到的,因此分析导致异常原因是解
    的头像 发表于 09-04 09:17 1779次阅读
    分享排查Linux系统<b class='flag-5'>CPU</b>占用的一个Shell脚本

    拓扑视图与实际拓扑结构间的差异

    简介 拓扑视图是硬件和网络编辑器的三个工作区中的一个。在此处可执行以下任务: 显示以太网拓扑 组态以太网拓扑 标识出指定拓扑结构与实际拓扑
    的头像 发表于 09-10 09:56 1064次阅读
    <b class='flag-5'>拓扑</b>视图与实际<b class='flag-5'>拓扑</b>结构间的<b class='flag-5'>差异</b>

    Java oom异常原因分析

    据,而栈内存用于存储方法调用和局部变量。 当程序需要使用更多内存时,会向操作系统请求更多的内存空间。如果操作系统无法分配足够的内存空间,就会导致OOM异常的发生。 导致OOM异常
    的头像 发表于 12-05 13:43 746次阅读

    cpu温度太高怎么解决?cpu温度高的原因

    cpu温度太高怎么解决?cpu温度高的原因CPU (中央处理器) 温度过高可能会导致系统崩溃、性能下降甚至损坏硬件,因此是一个需要严肃对
    的头像 发表于 12-09 16:15 3089次阅读

    如何解决C语言中的“访问权限冲突”异常?C语言引发异常原因分析

    如何解决C语言中的“访问权限冲突”异常?C语言引发异常原因分析  在C语言中,访问权限冲突异常通常是由于尝试访问未授权的变量、函数或其他数据
    的头像 发表于 01-12 16:03 5076次阅读