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

数据库 其他数据库 MongoDB
下面文章转载自火丁笔记,原作者描述了一次MongoDB数据迁移过程中遇到的性能问题及其解决方案,中间追查问题的方法和工具值得我们学习。

下面文章转载自火丁笔记,原作者描述了一次MongoDB数据迁移过程中遇到的性能问题及其解决方案,中间追查问题的方法和工具值得我们学习。

下面是其原文:

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

公司为这个项目专门配备了几台高性能务器,清一色的双路四核超线程CPU,外加32G内存,运维人员安装好MongoDB后,就轮到我了,我习惯于在使用新服务器前先看看相关日志,了解一下基本情况,当我浏览MongoDB日志时,发现一些警告信息:

  1. WARNING: You are running on a NUMA machine. 
  2. We suggest launching mongod like this to avoid performance problems: 
  3. numactl --interleave=all mongod [other options] 
当时我并不太清楚NUMA是什么东西,所以没有处理,只是把问题报告给了运维人员,事实证明运维人员也没有处理,所以问题的序幕就这样拉开了…

迁移工作首先要导入旧数据。开始一切倒还正常,不过几小时之后,我无意中发现不知道什么时候开始数据导入的速度下降了,同时我的PHP脚本开始不停的抛出异常:

  1. cursor timed out (timeout: 30000, time left: 0:0, status: 0) 

我一时判断不出问题所在,想想先在PHP脚本里加大Timeout的值应付一下:

  1. MongoCursor::$timeout = -1; 

可惜这样并没有解决问题,错误反倒变着花样的出现了:

  1. max number of retries exhausted, couldn't send query 
  2. couldn't send query: Broken pipe 
无奈之下用strace跟踪了一下PHP脚本:
  1. shell> strace -p  

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

  1. recvfrom(, 

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

  1. shell> apropos recvfrom 

还可以按照下面的方式确认一下:

  1. shell> lsof -p 
  2. shell> ls -l /proc//fd/ 
此时查询MongoDB当前操作,发现几乎每个操作会消耗大量的时间:
  1. shell> echo "db.currentOp()" | /path/to/mongo 

同时运行mongostat显示很高的locked值。

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

  1. mongo> use 
  2. mongo> db.setProfilingLevel(1); 
不过结果显示基本都是insert操作(因为我是导入数据为主),本身就不需要索引:
  1. mongo> use 
  2. mongo> db.system.profile.find().sort({$natural:-1}) 
  3. … 
问 题到了这里,似乎已经走投无路了,为了死马当活马医,我又重复了几次迁移旧数据的过程,结果自然是次次都出问题,但幸运的是我发现每当出问题的时候,在 top命令的结果中,总有一个名叫irqbalance的进程居高不下,搜索了一下,结果很多介绍irqbalance的文章中都提及了NUMA,让我一 下子记起之前在日志中看到的警告信息,于是乎按照信息里介绍的,重新启动了一下MongoDB:
  1. shell> numactl --interleave=all /path/to/mongod 

一切都正常了。为了解决这个问题,浪费了很多精神,实在没有力气再解释NUMA到底是什么东西了,有想了解的网友可以参考老外的文章,里面的介绍很翔实。

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

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

【编辑推荐】

  1. MongoDB之父:MongoDB胜过BigTable
  2. 主流NoSQL数据库全方位评测之MongoDB
  3. 教你如何利用MySQL学习MongoDB
  4. 在Windows环境下MongoDB搭建和简单操作
  5. Mongodb源码分析之Mongos分析
责任编辑:艾婧 来源: NoSQLFan
相关推荐

2023-01-05 11:44:43

性能HTTPS

2023-04-06 07:53:56

Redis连接问题K8s

2017-07-10 07:55:50

虚拟化Windows IO云计算

2021-05-13 08:51:20

GC问题排查

2021-03-29 12:35:04

Kubernetes环境TCP

2020-11-16 07:19:17

线上函数性能

2021-11-11 16:14:04

Kubernetes

2021-11-23 21:21:07

线上排查服务

2023-10-11 22:24:00

DubboRedis服务器

2020-08-10 11:00:02

Python优化代码

2021-03-01 06:14:50

环境高并发延迟

2022-02-08 17:17:27

内存泄漏排查

2021-10-14 10:53:20

数据库查询超时

2022-01-07 11:48:59

RabbitMQGolang 项目

2024-03-18 09:10:00

死锁日志binlog

2014-08-11 09:31:52

2017-07-07 16:07:41

2011-09-27 10:35:44

2020-08-12 08:25:43

数据库MySQL技术

2013-04-01 10:27:37

程序员失业
点赞
收藏

51CTO技术栈公众号