mongodb的NUMA问题

[loguser@32_180 ~]$ mongo -u root -p xxxxx --authenticationDatabase admin
MongoDB shell version: 2.6.4
connecting to: test
Server has startup warnings:
2015-07-16T04:35:34.694+0800 [initandlisten]
2015-07-16T04:35:34.694+0800 [initandlisten] ** WARNING: You are running on a NUMA machine.
2015-07-16T04:35:34.694+0800 [initandlisten] **          We suggest launching mongod like this to avoid performance problems:
2015-07-16T04:35:34.694+0800 [initandlisten] **              numactl --interleave=all mongod [other options]
2015-07-16T04:35:34.694+0800 [initandlisten]

解决方式：

1.在原启动命令前面加numactl –interleave=all

如# numactl –interleave=all ${MONGODB_HOME}/bin/mongod –config conf/mongodb.conf

2.改动内核參数

echo 0 > /proc/sys/vm/zone_reclaim_mode

http://www.mongodb.org/display/DOCS/NUMA

以下是NUMA简单介绍：

一、NUMA和SMP

NUMA和SMP是两种CPU相关的硬件架构。

在SMP架构里面。全部的CPU争用一个总线来訪问全部内存，长处是资源共享，而缺点是总线争用激烈。随着PC服务器上的CPU数量变多（不不过CPU核数）。总线争用的弊端慢慢越来越明显，于是Intel在Nehalem CPU上推出了NUMA架构。而AMD也推出了基于同样架构的Opteron CPU。

NUMA最大的特点是引入了node和distance的概念。

对于CPU和内存这两种最宝贵的硬件资源，NUMA用近乎严格的方式划分了所属的资源组（node）。而每一个资源组内的CPU和内存是差点儿相等。

资源组的数量取决于物理CPU的个数（现有的PC server大多数有两个物理CPU。每一个CPU有4个核）；distance这个概念是用来定义各个node之间调用资源的开销，为资源调度优化算法提供数据支持。

二、NUMA相关的策略

1、每一个进程（或线程）都会从父进程继承NUMA策略，并分配有一个优先node。

假设NUMA策略同意的话，进程能够调用其它node上的资源。

2、NUMA的CPU分配策略有cpunodebind、physcpubind。

cpunodebind规定进程执行在某几个node之上，而physcpubind能够更加精细地规定执行在哪些核上。

3、NUMA的内存分配策略有localalloc、preferred、membind、interleave。

localalloc规定进程从当前node上请求分配内存。而preferred比較宽松地指定了一个推荐的node来获取内存，假设被推荐的node上没有足够内存，进程能够尝试别的node。

membind能够指定若干个node。进程只能从这些指定的node上请求分配内存。interleave规定进程从指定的若干个node上以RR算法交织地请求分配内存。

三、NUMA和swap的关系

可能大家已经发现了。NUMA的内存分配策略对于进程（或线程）之间来说，并非公平的。

在现有的Redhat Linux中，localalloc是默认的NUMA内存分配策略。这个配置选项导致资源独占程序非常easy将某个node的内存用尽。

而当某个node的内存耗尽时，Linux又刚好将这个node分配给了某个须要消耗大量内存的进程（或线程）。swap就妥妥地产生了。

虽然此时还有非常多page cache能够释放。甚至还有非常多的free内存。

四、解决swap问题

虽然NUMA的原理相对复杂，实际上解决swap却非常简单：只要在启动MySQL之前使用numactl –interleave来改动NUMA策略就可以。

值得注意的是。numactl这个命令不只能够调整NUMA策略，也能够用来查看当前各个node的资源是用情况，是一个非常值得研究的命令。