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，性能会有些许提升，但带来的结果偏差会变得很大。