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