numa 架构下的 mysql，mongodb数据库

从MySQL迁移到MongoDB，在导入旧数据的过程中，遇到了些许波折，犯了不少错误，但同时也学到了不少知识，遂记录下来。

公司为这个项目专门配备了几台高性能务器，清一色的双路四核超线程CPU，外加32G内存，运维人员安装好MongoDB后，就轮到我了，我习惯于在使用新服务器前先看看相关日志，了解一下基本情况，当我浏览MongoDB日志时，发现一些警告信息：
WARNING: You are running on a NUMA machine.
We suggest launching mongod like this to avoid performance problems:
numactl --interleave=all mongod [other options]
当时我并不太清楚NUMA是什么东西，所以没有处理，只是把问题报告给了运维人员，事实证明运维人员也没有处理，所以问题的序幕就这样拉开了…

迁移工作首先要导入旧数据。开始一切倒还正常，不过几小时之后，我无意中发现不知道什么时候开始数据导入的速度下降了，同时我的PHP脚本开始不停的抛出异常：
cursor timed out (timeout: 30000, time left: 0:0, status: 0)
我一时判断不出问题所在，想想先在PHP脚本里加大Timeout的值应付一下：
MongoCursor::$timeout = -1;
可惜这样并没有解决问题，错误反倒变着花样的出现了：
max number of retries exhausted, couldn't send query
couldn't send query: Broken pipe
无奈之下用strace跟踪了一下PHP脚本：
shell> strace -p <PID>
发现进程卡在了recvfrom操作上：
recvfrom(<FD>,
通过如下命令查询recvfrom操作的含义是：receive a message from a socket
shell> apropos recvfrom
还可以按照下面的方式确认一下：
shell> lsof -p <PID>
shell> ls -l /proc/<PID>/fd/<FD>
此时查询MongoDB当前操作，发现几乎每个操作会消耗大量的时间：
shell> echo "db.currentOp()" | /path/to/mongo
同时运行mongostat显示很高的locked值。

…

重复做了很多工作，但始终无法找到问题的症结在哪里，只好求助官方论坛，那里的技术支持都很热心，在我描述了问题后，没过多久就有了回复，建议我检查一下是不是索引不佳所致，为了验证这种可能，我激活了Profiler记录慢操作：
mongo> use <DB>
mongo> db.setProfilingLevel(1);
不过结果显示基本都是insert操作（因为我是导入数据为主），本身就不需要索引：
mongo> use <DB>
mongo> db.system.profile.find().sort({$natural:-1})
…

问题到了这里，似乎已经走投无路了，为了死马当活马医，我又重复了几次迁移旧数据的过程，结果自然是次次都出问题，但幸运的是我发现每当出问题的时候，在top命令的结果中，总有一个名叫irqbalance的进程居高不下，搜索了一下，结果很多介绍irqbalance的文章中都提及了NUMA，让我一下子记起之前在日志中看到的警告信息，于是乎按照信息里介绍的，重新启动了一下MongoDB：
shell> numactl --interleave=all /path/to/mongod
一切都正常了。为了解决这个问题，浪费了很多精神，实在没有力气再解释NUMA到底是什么东西了，有想了解的网友可以参考老外的文章，里面的介绍很翔实。

原文链接：huoding.com

对于罪魁祸首，作者留给大家去学习，NoSQLFan在这里可以给大家做一个简单的描述，先解释几个概念

NUMA：NUMA是多核心CPU架构中的一种，其全称为Non-Uniform Memory Access，简单来说就是在多核心CPU中，机器的物理内存是分配给各个核的，架构简图如下所示：

每个核访问分配给自己的内存会比访问分配给其它核的内存要快，有下面几种访问控制策略：

1.缺省(default)：总是在本地节点分配（分配在当前进程运行的节点上）；
2.绑定(bind)：强制分配到指定节点上；
3.交叉(interleave)：在所有节点或者指定的节点上交织分配；
4.优先(preferred)：在指定节点上分配，失败则在其他节点上分配。

上面文章中最后使用numactl –interleave命令就是指定其为交叉共享模式。

irqbalance：这是作者在上面提到的一个占用CPU的进程，这个进程的作用是在多核心CPU的操作系统中，分配系统中断信号的。参见：irqbalance.org

概念说完了，下面是上面问题的简单描述：

我们知道虚拟内存机制是通过一个中断信号来通知虚拟内存系统进行内存swap的，所以这个irqbalance进程忙，是一个危险信号，在这里是由于在进行频繁的内存交换。这种频繁交换现象称为swap insanity，在MySQL中经常提到，也就是在NUMA框架中，采用不合适的策略，导致核心只能从指定内存块节点上分配内存，即使总内存还有富余，也会由于当前节点内存不足时产生大量的swap操作。

相对于SMP(又称uniform. memory architecture),NUMA引入了node的概念，每个物理CPU都被视作一个node，而每个node都有一个local memory（访问速度更快），其他node的内存则为remote；

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上以Round-roll算法交织地请求分配内存。

在现有的Redhat Linux中，localalloc是默认的NUMA内存分配策略，这个配置选项导致资源独占程序很容易将某个node的内存用尽。而当某个node的内存耗尽时，Linux又刚好将这个node分配给了某个需要消耗大量内存的进程（或线程），此时即便其他node有空闲内存也无济于事，于是就产生了swap

可通过numactl查看相关信息

numactl --hardware查看

# numactl --hardware

available: 2 nodes (0-1)

node 0 size: 32276 MB

node 0 free: 26856 MB

node 1 size: 32320 MB

node 1 free: 26897 MB

node distances:

node 0 1

0: 10 21

1: 21 10