NUMA对性能的影响

事出这一段时间做了不少基于SPECjbb2005的系统性能测试,发觉对于不少平台,可以出现相当大的采样偏差,而有这么一台主机却表现的相当稳定。仔细排查之后,最终定位到了NUMA。

之前曾经介绍过NUMA的原理以及基于Cgroup的NUMA设定

这次我采用的是通过docker封装好的SPECjbb2005,Docker从本质上说底层就是一个cgroup。

首先是机器的NUMA拓扑:

# # numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
node 0 size: 130502 MB
node 0 free: 123224 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 1 size: 131072 MB
node 1 free: 126082 MB
node distances:
node 0 1
 0: 10 21
 1: 21 10

开启HT之后,系统显示64个core,其中core 0-15,32-47位于NUMA node0,Core16-31,48-63 位于 NUMA node1

通过限制cpuset-cpus,cpuset-mems只允许SPECjbb运行在core 0-15,32-47,并只能访问NUMA node1

docker run --cpuset-cpus=0-15,32-47 --cpuset-mems=0 specjbb

然后就是之允许方位node1

docker run --cpuset-cpus=0-15,32-47 --cpuset-mems=1 specjbb

最后就是不做任何限定

docker run --cpuset-cpus=0-15,32-47 specjbb

一开始我自己觉得这3个场景的性能差异应该不会很大,谁知道拿出数据来之后我傻了。

SPECjbb 2005 得分1 差距1 SPECjbb 2005 得分2 差距2
场景1 882912.91 0.4% 256094.32 8.1%
场景 3 886731.13 278767.92
场景2 628329.09 29.1% 188030.75 26.6%

几个误区:

  • 只允许CPU访问自己本地的NUMA node并不能得到最高的性能,有的时候NUMA node也有性能瓶颈。
  • 错误的NUMA设置其实会带来相当大的性能差距。
  • 还有一个从上表的数据上看不出来:一旦你设置了允许CPU访问任何一个node,性能会有些许提升,但带来的结果偏差会变得很大。
推荐阅读:
事出前些日子有人咨询我:“在某
时延 latency(亦称为延
似乎每次开头都要讲述一下计算机

“NUMA对性能的影响”的3个回复

  1. 您好!可以分享一下您的SPECjbb2005 dockerfile文件吗?最近需要用到SPECjbb2005进行测试。我的邮箱是:*****163.com

发表评论

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

请补全下列算式: *

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