记一次MongoDB性能问题,附原理解析

标签: MongoDB irqbalance NUMA 多核 | 发表时间:2011-08-10 11:02 | 作者:nosqlfan zffl
出处:http://blog.nosqlfan.com

下面文章转载自火丁笔记,原作者描述了一次MongoDB数据迁移过程中遇到的性能问题及其解决方案,中间追查问题的方法和工具值得我们学习。另外NoSQLFan还对作者略讲的问题产生原理进行了分析,希望对您有用。

下面是其原文:

最近忙着把一个项目从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操作。

对于NUMA,进一步了解可以参考:NUMA与英特尔下一代Xeon处理器 和 MySQL单机多实例方案 两篇文章

技术传播,需要你我共同努力!    

相关文章:

Mongoid:一个MongoDB的Ruby ODM封装

MongoDB1.6版本与最新1.8版本性能测试——写入篇

mongodb的javascript性能

MongoDB paddingFactor的含义

MongoDB性能优化十大指标
无觅

相关 [mongodb 性能 问题] 推荐:

记一次MongoDB性能问题

- Fstone - 火丁笔记
最近忙着把一个项目从MySQL迁移到MongoDB,在导入旧数据的过程中,遇到了些许波折,犯了不少错误,但同时也学到了不少知识,遂记录下来. 公司为这个项目专门配备了几台高性能务器,清一色的双路四核超线程CPU,外加32G内存,运维人员安装好MongoDB后,就交我手里了,我习惯于在使用新服务器前先看看相关日志,了解一下基本情况,当我浏览MongoDB日志时,发现一些警告信息:.

记一次MongoDB性能问题,附原理解析

- zffl - NoSQLFan
下面文章转载自火丁笔记,原作者描述了一次MongoDB数据迁移过程中遇到的性能问题及其解决方案,中间追查问题的方法和工具值得我们学习. 另外NoSQLFan还对作者略讲的问题产生原理进行了分析,希望对您有用. 最近忙着把一个项目从MySQL迁移到MongoDB,在导入旧数据的过程中,遇到了些许波折,犯了不少错误,但同时也学到了不少知识,遂记录下来.

mongodb性能测试

- - 数据库 - ITeye博客
1) Mongodb的非安全插入方式,在一开始插入性能是非常高的,但是在达到了两千万条数据之后性能骤减,这个时候恰巧是服务器24G内存基本占满的时候(随着测试的进行mongodb不断占据内存,一直到操作系统的内存全部占满),也就是说Mongodb的内存映射方式,使得数据全部在内存中的时候速度飞快,当部分数据需要换出到磁盘上之后,性能下降很厉害.

MongoDB智能查询优化的问题

- - NoSQLFan
自动 查询优化是 MongoDB一个专门设计的功能. 简言之,这个功能就是通过对查询进行分析,从而判断出更有利的索引使用策略. 而这个智能的功能,实际潜伏着一些问题. 传统的查询优化是通过对语句进行语义分析来进行索引使用的预判,而MongoDB使用了一种更简单粗暴的方式,对查询的实际执行情况进行分析,它同时执行多条查询,每一条查询使用不同的索引,当其中一条返回时,终止其它的查询,并记录这次的结果,以后会优先使用返回更快的索引.

mongodb索引讲解与性能调优

- - haohtml's blog
mongodb索引规则基本上与传统的关系库一样,大部分优化MySQL/Oracle/SQLite索引的技巧也适用于mongodb. 当查询中用到某些条件时,可以对该键建立索引,以提高查询速度. 如果数据量很多且查询多于更新时,可以用索引提高查询的速度. a)         查询索引:. 查询索引很简单,比如说需要查询mailaccess数据库中的Mail collection上的索引时:.

Cassandra HBase和MongoDb性能比较

- - 数据库 - ITeye博客
这是一篇基于亚马逊云平台上对三个主流的. NoSQL数据库性能比较,在读写两个操作不同的组合情况下性能表现不同. 横坐标是吞吐量,纵坐标是延迟,这是一对矛盾,吞吐量越大,延迟越低,代表越好. 纯粹插入,Cassandra领先,见下图:. 2.WorkloadA: 读修改操作各占一半情况下的修改性能:MongoDB明显延迟增加,落败:.

[Cacti] mongodb性能监控实战

- - CSDN博客数据库推荐文章
          为了更好的使用mongodb,需要监控出mongodb的一些基础使用情况,比如Flush数、连接数、内存使用率、Index操作,Slave延迟等等,这些可以通过配置cacti监控mongodb的模板来完成. 1,在cacti界面导入模板 在计算机本地,下载此tgz包:http://mysql-cacti-templates.googlecode.com/files/better-cacti-templates-1.1.8.tar.gz.

开发高性能的MongoDB应用—浅谈MongoDB性能优化 - 吴纹羽

- - 博客园_首页
大数据时代的数据存储,非关系型数据库MongoDB(一).   “如何能让软件拥有更高的性能. ”,我想这是一个大部分开发者都思考过的问题. 性能往往决定了一个软件的质量,如果你开发的是一个互联网产品,那么你的产品性能将更加受到考验,因为你面对的是广大的 互联网用户,他们可不是那么有耐心的. 严重点说,页面的加载速度每增加一秒也许都会使你失去一部分用户,也就是说, 加载速度和用户量是成反比的.

三招解决MongoDB的磁盘IO问题

- - NoSQLFan
有点标题党的意思,不过下面三招确实比较实用,内容来自 Conversocial公司的VP Colin Howe在London MongoDB用户组的一个分享. 申请:下面几点并非放四海皆准的法则,具体是否能够使用,还需要根据自己的应用场景和数据特点来决定. 我们知道MongoDB是一个文档数据库,其每一条记录都是一个JSON格式的文档.

Mongodb亿级数据量的性能测试

- - haohtml's blog
进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目:.  (所有插入都是单线程进行,所有读取都是多线程进行). 1) 普通插入性能 (插入的数据每条大约在1KB左右). 2) 批量插入性能 (使用的是官方C#客户端的InsertBatch),这个测的是批量插入性能能有多少提高. 3) 安全插入功能 (确保插入成功,使用的是SafeMode.True开关),这个测的是安全插入性能会差多少.