UMA/NUMA之性能差异

继续在NUMA和性能差异的路上走下去。

之前写过一片东西http://www.litrin.net/2017/08/03/numa%e5%af%b9%e6%80%a7%e8%83%bd%e7%9a%84%e5%bd%b1%e5%93%8d/ 讲的是一个基于SPECjbb2005的快速测试给大家做了一个对于UMA/NUMA的直观介绍。这篇就是针对不同的计算类型,介绍下NUMA是如何对性能做出改变的。

考虑到之前对于JVM应用场景过于单一,不同于之前的SPECjbb2005,这次我们采用的是SPEC CPU2006。其实本想采用更为激进的SPEC CPU2017但考虑到2017版本对于新CPU的优化过于偏袒,而这次的测试事实上是要“更多的体现性能差距”,而没有采用新版本。
同时,传统的整数运算对于内存/QPI带宽的消耗事实上是有限的,大部分的整数性能只跟CPU频率相关,这里我们只用SPEC CPU2006的浮点计算作为基准,忽略整数部分。同时,优化编译采用了最新的AVX指令集以确保性能最优。

测试的平台我们动了一点小手脚,允许我们手工调整QPI的最大带宽,在测试数据中将通过”turbo”标记区别。注意,这个turbo不是指CPU的turbo技术,turbo之后的QPI最大带宽将会比正常状态增加约1/3。也就是说:turbo标记只意味着增加了额外的QPI带宽。

重点来了,放出数据!

  1. 对于表上的大多数数据来说,增加额外的QPI带宽都会从一定成都上提升计算性能,这使得SPEC CPU的总分上升了11.21%。性能提升以410.bwaves组件最为明显。部分组件如454.calculix的测试成绩基本保持不变(5%以内的变化可以等同没有变化)。
  2. 开启NUMA支持之后,跑分有12%的提升,相比增加QPI带宽的方式略有提升。部分组件有了接近50%的性能提升,但部分组件如459.GemsFDTD则有了大幅的性能下降。
  3. 开启NUMA之后,额外的QPI带宽并没有带来本质上的性能提升。

下面我们将针对几个有代表性的组件测试一一展开分析。

对于提升QPI带宽后性能有提升的样本我们采用了性能提升最为显著的410.bwaves。作为对照组,我们选择了454.calculix作为参照。

首先是bwaves的QPI占用率曲线。

这里可以看到,在整个UMA场景下的运行过程中,bwaves对于QPI的带宽消耗是非常明显的,一直处在85%以上的高位水平。在这个基础之上,QPI的带宽是绝对意义上的瓶颈。提升了QPI带宽,性能自然就会得到提升。
同样,开启了NUMA之后,跨NUMA node之间的通讯被关闭,UPI的消耗自然就会降到了几乎没有的水平。这也映证了bwaves可以在NUMA场景下得到性能提升的结果。

反观参照组的calculix:

增加了额外的QPI带宽之后,QPI的平均利用率从~60%下降到了~40%——这恰恰正是QPI提升的比例。也就是说,对于这样的应用,QPI本身并不是瓶颈,再怎么提升QPI带宽,性能也无法得到本质上的提升。而且从其NUMA场景下的跑分来看,本质上它也没有从NUMA中受益。

回过头我们来看看为什么会有程序会在开启NUMA之后性能下降。

以459.GemsFDTD组件为例,我们记录了它在开关NUMA过程中的几个指标“DDR data rate(MT/second)” 是内存每秒百万操作次数;“memory RPQ latency ”是内存读的过程中操作的返回时间——严格意义上讲,这其实是一个指标的两种不同的表达方式。

由上图可以看的出,开启NUMA之后,每秒进行的内存操作下降,每次操作的返回时间上升了接近一倍。这意味着更多的时间被消耗在了“等待读写内存返回”的过程中。性能自然好不到哪里去。对于内存时延比较敏感的操作,NUMA只会带来性能下降。

总结下来:

增加QPI带宽好比修路,而开启NUMA好比限流。

  • 不是每个系统都允许“修路”,但“限流”则是代价很低。
  • 即便没有交通拥堵,修路之后,至少不会影响到现有的交通。
  • 对于很多情况下“限流”会让你不得不公交出行,道路利用率提升,性能也会得到提升。对于特殊需求来说,限流之后性能会下降。

 

推荐阅读:
事出前些日子有人咨询我:“在某
时延 latency(亦称为延
似乎每次开头都要讲述一下计算机

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请补全下列算式: *

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据