mongodb性能问题及原理分析

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

公司为这个项目专门配备了几台高性能务器，清一色的双路四核超线程CPU，外加32G内存，运维人员安装好MongoDB后。就轮到我了。我习惯于在使用新server前先看看相关日志。了解一下基本情况。当我浏览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 

发现进程卡在了recvfrom操作上：

recvfrom(,

通过例如以下命令查询recvfrom操作的含义是：receive a message from a socket

shell> apropos recvfrom

还能够依照以下的方式确认一下：

shell> lsof -p 
shell> ls -l /proc//fd/

此时查询MongoDB当前操作。发现差点儿每一个操作会消耗大量的时间：

shell> echo "db.currentOp()" | /path/to/mongo

同一时候执行mongostat显示非常高的locked值。

…

反复做了非常多工作。但始终无法找到问题的症结在哪里，仅仅好求助官方论坛，那里的技术支持都非常热心，在我描写叙述了问题后，没过多久就有了回复，建议我检查一下是不是索引不佳所致，为了验证这样的可能，我激活了Profiler记录慢操作：

mongo> use 
mongo> db.setProfilingLevel(1);

只是结果显示基本都是insert操作（由于我是导入数据为主），本身就不须要索引：

mongo> use 
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操作。

对于NUMA。进一步了解能够參考：NUMA与英特尔下一代Xeon处理器 和MySQL单机多实例方案 两篇文章