咱们公司的基础架构部有个云Redis平台，其中Redis实例在申请的时候能够自由选择须要的内存的大小。而后就引发了我的一个思考，Redis单实例内存最大申请到多大比拟适合？假如母机是64GB内存的物理机，如果不思考CPU资源的的节约，我是否能够开一个50G的Redis实例？

于是我在Google上各种搜寻，探讨这个问题的人仿佛不多。找到惟一感觉靠谱点的答案，那就是单过程调配的内存最好不要超过一个node里的内存总量，否则linux当该node里的内存调配光了的时候，会在本人node里动用硬盘swap，而不是其它node里申请。这即便所谓的numa陷阱，当Redis进入这种状态后会导致性能急剧下降（不只是redis，所有的内存密集型利用如mysql，mongo等都会有相似问题）。

看起来这个解释十分有说服力。于是乎，我就想亲手捕获一次NUMA陷阱，看看这个家伙到底什么样。

先聊聊QPI与NUMA

最早在CPU都是单核的时候，用的总线都是FSB总线。经典构造如下图：

到来起初CPU的开发者们发现CPU的频率曾经靠近物理极限了，没法再有更大程度的进步了。在2003年的时候，CPU的频率就曾经达到2个多GB，甚至3个G了。当初你再来看明天的CPU，根本也还是这个频率，没提高多少。摩尔定律生效了，或者说是向另外一个方向倒退了。那就是多核化、多CPU化。

刚开始核不多的时候，FSB总线勉强还能够撑持。然而随着CPU越来越多，所有的数据IO都通过这一条总线和内存叫唤数据，这条FSB就成为了整个计算机系统的瓶颈。举个北京的例子，这就好比进回龙观的京藏高速，刚开始回龙观人口不多的时候，这条高速承载没问题。然而当初回龙观汇集了几十万人了，“总线”还仅有这一条，未免效率太低。

CPU的设计者们很快扭转了本人的设计，引入了QPI总线，相应的CPU的构造就叫NMUA架构。下图直观了解

话说NUMA陷阱

NUMA陷阱指的是引入QPI总线后，在计算机系统里可能会存在的一个坑。大抵的意思就是如果你的机器关上了numa，那么你的内存即便在短缺的状况下，也会应用磁盘上的swap，导致性能低下。起因就是NUMA为了高效，会仅仅只从你的以后node里分配内存，只有以后node里用光了（即便其它node还有），也依然会启用硬盘swap。

当我第一次据说到这个概念的时候，不禁感叹我运气好，我的Redis实例貌似素来没有掉进这个陷阱里过。那为了当前也别栽坑，连忙去理解了下我的机器的numa状态：

# numactl --hardwareavailable: 2 nodes (0-1)node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17node 0 size: 32756 MBnode 0 free: 19642 MBnode 1 cpus: 6 7 8 9 10 11 18 19 20 21 22 23node 1 size: 32768 MBnode 1 free: 18652 MBnode distances:node   0   1  0:  10  21  1:  21  10

下面后果阐明咱们有两个node，node0和node1，别离有12个外围，各有32GB的内存。
再看zone_reclaim_mode，它用来治理当一个内存区域(zone)外部的内存耗尽时，是从其外部进行内存回收还是能够从其余zone进行回收的选项：

  • 0 敞开zone_reclaim模式，能够从其余zone或NUMA节点回收内存
  • 1 关上zone_reclaim模式，这样内存回收只会产生在本地节点内
  • 2 在本地回收内存时，能够将cache中的脏数据写回硬盘，以回收内存
  • 4 在本地回收内存时，示意能够用Swap 形式回收内存
# cat /proc/sys/vm/zone_reclaim_mode1

额，好吧。我的这台机器上的zone_reclaim_mode还真是1，只会在本地节点回收内存。

实际捕获numa陷阱得逞

那我的好奇心就来了，既然我的单个node节点只有32G，那我部署一个50G的Redis，给它填满数据试试到底会不会产生swap。

试验开始，我先查看了本地总内存，以及各个node的内存残余情况。

# top......Mem:  65961428k total, 26748124k used, 39213304k free,   632832k buffersSwap:  8388600k total,        0k used,  8388600k free,  1408376k cached# cat /proc/zoneinfo"  ......Node 0, zone   Normal  pages free     4651908Node 1, zone   Normal  pages free     4773314

总内存不必解释，/proc/zoneinfo里蕴含了node可供应用程序申请的free pages。node1有4651908个页面，4651908\*4K=18G的可用内存。

接下来让咱们启动redis实例，把其内存下限设置到超过单个node里的内存大小。我这里单node内存大小是32G，我把redis设置成了50G。开始灌入数据。最终数据全副灌完之后，

# topMem:  65961428k total, 53140400k used, 12821028k free,   637112k buffersSwap:  8388600k total,        0k used,  8388600k free,  1072524k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 8356 root      20   0 62.8g  46g 1292 S  0.0 74.5   3:45.34 redis-server # cat /proc/zoneinfo | grep "pages free"  pages free     3935  pages free     347180  pages free     1402744  pages free     1501670

试验证实，在zone_reclaim_mode为1的状况下，Redis是均匀在两个node里申请节点的，并没有固定在某一个cpu里。

莫非是大佬们的忠告错了吗？其实不是，如果不绑定亲和性的话，分配内存是当过程在哪个node上的CPU发动内存申请，就优先在哪个node里分配内存。之所以是平均分配在两个node里，是因为redis-server过程试验中常常会进入被动睡眠状态，醒来后可能CPU就换了。所以基本上，最初看起来内存是平均分配的。如下图，CPU进行了500万次的上下文切换，用top命令看到cpu也是在node0和node1跳来跳去。

# grep ctxt /proc/8356/statusvoluntary_ctxt_switches:        5259503nonvoluntary_ctxt_switches:     1449

改良办法，胜利抓获numa陷阱

杀死过程，内存归位

# cat /proc/zoneinfo Node 0, zone   Normal  pages free     7597369Node 1, zone   Normal  pages free     7686732

绑定CPU和内存的亲和性，而后再启动。

numactl --cpunodebind=0 --membind=0 /search/odin/daemon/redis/bin/redis-server /search/odin/daemon/redis/conf/redis.conf

top命令察看到CPU的确始终在node0的节点里。node里的内存也在疾速耗费。

# cat /proc/zoneinfo Node 0, zone   Normal  pages free     10697Node 1, zone   Normal  pages free     7686732

看，内存很快就耗费光了。咱们再看top命令察看到的swap，很冲动地发现，我终于陷入到传说中的numa陷阱了。

Tasks: 603 total,   2 running, 601 sleeping,   0 stopped,   0 zombieCpu(s):  0.7%us,  5.4%sy,  0.0%ni, 85.6%id,  8.2%wa,  0.0%hi,  0.1%si,  0.0%stMem:  65961428k total, 34530000k used, 31431428k free,   319156k buffersSwap:  8388600k total,  6000792k used,  2387808k free,   777584k cached  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  258 root      20   0     0    0    0 R 72.3  0.0   0:17.18 kswapd025934 root      20   0 37.5g  30g 1224 D 71.6 48.7   1:06.09 redis-server

这时候，Redis理论应用的物理内存RES定格到了30g不再上涨，而是开始耗费Swap。

又过了一会儿，Redis被oom给kill了。

论断

通过明天的试验，咱们能够发现的确有NUMA陷阱这种货色存在。不过那是我手工通过numactl指令绑定cpu和mem的亲和性后才遭逢的。置信国内绝大部分的线上Redis没有进行这个绑定，所以实践上来单Redis单实例能够应用到整个机器的物理内存。（实际中最好不要这么干，你的大部分内存都绑定到一个redis过程里的话，那其它CPU核就没啥事干了，节约了CPU的多核计算能力）

扩大

当通过numactl绑定CPU和mem都在一个node里的时候，内存IO不须要通过总线，性能会比拟高，你Redis的QPS能力也会上涨。和跨node的内存IO性能比照，能够上面的实例，就是10:21的区别。

# numactl --hardware......node distances:node   0   1  0:  10  21  1:  21  10

你要是对性能有极致的谋求，能够试着绑定numa的亲和性玩玩。不过，no作no die，掉到numa陷阱里可别赖我，嘎嘎！

开发内功修炼之内存篇专辑：

  • 1.带你深刻了解内存对齐最底层原理
  • 2.内存随机也比程序拜访慢，带你深刻了解内存IO过程
  • 3.从DDR到DDR4，内存外围频率其实基本上就没太大的提高
  • 4.理论测试内存在程序IO和随机IO时的拜访延时差别
  • 5.揭穿内存厂家“谎话”，实测内存带宽实在体现
  • 6.NUMA架构下的内存拜访提早区别！
  • 7.PHP7内存性能优化的思维精华
  • 8.一次内存性能晋升的我的项目实际
  • 9.挑战Redis单实例内存最大极限，“遭逢”NUMA陷阱！

我的公众号是「开发内功修炼」，在这里我不是单纯介绍技术实践，也不只介绍实践经验。而是把实践与实际联合起来，用实际加深对实践的了解、用实践进步你的技术实际能力。欢送你来关注我的公众号，也请分享给你的好友~~~