NUMA对性能的影响

标签: 硬件相关 | 发表时间:2017-08-03 10:20 | 作者:Litrin
出处:http://www.litrin.net

事出这一段时间做了不少基于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,性能会有些许提升,但带来的结果偏差会变得很大。

相关 [numa 性能] 推荐:

NUMA对性能的影响

- - 开源小站
事出这一段时间做了不少基于SPECjbb2005的系统性能测试,发觉对于不少平台,可以出现相当大的采样偏差,而有这么一台主机却表现的相当稳定. 仔细排查之后,最终定位到了NUMA. 之前曾经介绍过 NUMA的原理以及基于 Cgroup的NUMA设定. 这次我采用的是通过docker封装好的SPECjbb2005,Docker从本质上说底层就是一个cgroup.

修改numa和io调度优化mysql性能

- 高春辉 - C1G军火库
单机单实例,建议关闭NUMA,关闭的方法有三种:. 1.硬件层,在BIOS中设置关闭;. 2.OS内核,启动时设置numa=off;. 3.可以用numactl命令将内存分配策略修改为interleave(交叉). 修改mysql.server 330行加上numactl. numastat 查看内存分配.

NUMA微架构

- - 夏清然的日志
现在开始补日志,逐步的扫清以前写了一半的和“欠账未还的”. 半年之前开的头,今天先把NUMA说完. PC硬件结构近5年的最大变化是多核CPU在PC上的普及,多核最常用的SMP微架构:. 多个CPU之间是平等的,无主从关系(对比IBM Cell);. 多个CPU平等的访问系统内存,也就是说内存是统一结构、统一寻址的(UMA,Uniform Memory Architecture);.

深挖NUMA

- - 开源小站
首先列出本站之前相关的几篇帖子:. cgroup的cpuset问题. 这次,就来深入了解下NUMA. 就如之前说的,在若干年前,对于x86架构的计算机,那时的内存控制器还没有整合进CPU,所有内存的访问都需要通过北桥芯片来完成. 此时的内存访问如下图所示,被称为UMA( uniform memory access, 一致性内存访问  ).

NUMA技术相关笔记

- - CSDN博客架构设计推荐文章
起源于在mongo启动脚本中看到numactl --interleave=all mongod .... NUMA,非统一内存访问(Non-uniform Memory Access),介于SMP(对称多处理)和MPP(大规模并行处理)之间,各个节点自有内存(甚至IO子系统),访问其它节点的内存则通过高速网络通道.

NUMA 架构中 MySQL 的 “swap insanity” 问题

- khsing - Linux@SOHU
翻译:王鑫、朱翊然、李凯、曾怀东、马少兵、林业. 在一台包括了2个4核CPU,64GB内存的服务器上,给 MySQL 配置了 48GB 之巨的 InnoDB 缓冲,随着时间的推移,尽管观察到的数据(见最后注1)表示并没有真正的内存压力,Linux 也会把大量的内存交换到磁盘上. 通过监控发现,配置的内存超过了实际所需,而且也不存在内存泄漏,mysqld的RSS占用正常且稳定.

NUMA架构的CPU -- 你真的用好了么?

- - cenalulu's Tech Blog
本文从NUMA的介绍引出常见的NUMA使用中的陷阱,继而讨论对于NUMA系统的优化方法和一些值得关注的方向. 文章欢迎转载,但转载时请保留本段文字,并置于文章的顶部. 作者:卢钧轶(cenalulu). 本文原文地址: http://cenalulu.github.io/linux/numa/.

MySQL 性能

- - 谁主沉浮
这里罗列了一些基本的 MySQL 性能提示,但不是放之四海而皆准,需要根据实际的应用情况而决定. 使用标准化设计(数据库三范式),记住表的联合查询(join)性能不会差. 选择合适的字符集,虽然UTF16无所不能,但需要两倍的存储;UTF8适合各种字符,但比latin1慢,尽可能选用latin1(此条不适合中文).

性能监控

- - 互联网 - ITeye博客
一旦你的服务器是在控制台模式下运行,你就可以开始我们接下来的内容. iostat  iostat 命令用来显示存储子系统的详细信息,通常用它来监控磁盘 I/O 的情况. 要特别注意 iostat 统计结果中的 %iowait 值,太大了表明你的系统存储子系统性能低下. meminfo 和 free  Meminfo 可让你获取内存的详细信息,你可以使用 cat 和 grep 命令来显示 meminfo 信息: 1 cat /proc/meminfo  另外你可以使用 free 命令来显示动态的内存使用信息,free 只是给你大概的内存信息,而 meminfo 提供的信息更加详细.

高性能mysql 之 性能剖析

- - 数据库 - ITeye博客
1 定义性能优化 mysql服务器性能,此处定义为 响应时间. 在解释性能优化之前,先来消除一个误解,很多人认为,性能优化就是降低cpu的利用率或者减少对资源的使用. 资源时用来消耗并用来工作的,所以有时候消耗更多的资源能够加快查询速度,保持cpu忙绿,这是必要的. 很多时候发现 编译进了新版本的InnoDB之后,cpu利用率上升的很厉害,这并不代表性能出现了问题.