记一次MongoDB性能问题+Linux内存管理学习笔记--物理内存分配_mysql

最近忙着把一个项目从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是什么东西，所以没有处理，只是把问题反馈给了运维人员，后来知道运维人员也没有理会这茬儿，所以问题的序幕就这样拉开了。

迁移工作需要导入旧数据。MongoDB本身有一个mongoimport工具可供使用，不过它只接受json、csv等格式的源文件，不适合我的需求，所以我没用，而是用PHP写了一个脚本，平稳运行了一段时间后，我发现数据导入的速度下降了，同时PHP抛出异常：

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

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

<?php

MongoCursor::$timeout = -1;

?>

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

max number of retries exhausted, couldn’t send query, couldn’t send query: Broken pipe

接着使用strace跟踪了一下PHP脚本，发现进程卡在了recvfrom操作上：

shell> strace -f -r -p <PID>
recvfrom(<FD>,

通过如下命令查询recvfrom操作的含义：

shell> apropos recvfrom
receive a message from a socket

或者按照下面的方式确认一下：

shell> lsof -p <PID>
shell> ls -l /proc/<PID>/fd/<FD>

此时如果查询MongoDB的当前操作，会发现几乎每个操作会消耗大量的时间：

mongo> db.currentOp()

与此同时，运行mongostat的话，结果会显示很高的locked值。

…

我在网络上找到一篇：MongoDB Pre-Splitting for Faster Data Loading and Importing，看上去和我的问题很类似，不过他的问题实质是由于自动分片导致数据迁移所致，解决方法是使用手动分片，而我并没有使用自动分片，自然不是这个原因。

…

询问了几个朋友，有人反映曾遇到过类似的问题，在他的场景里，问题的主要原因是系统IO操作繁忙时，数据文件预分配堵塞了其它操作，从而导致雪崩效应。

为了验证这种可能，我搜索了一下MongoDB日志：

shell> grep FileAllocator /path/to/log
[FileAllocator] allocating new datafile ... filling with zeroes...
[FileAllocator] done allocating datafile ... took ... secs

我使用的文件系统是ext4（xfs也不错），创建数据文件非常快，所以不是这个原因，但如果有人使用ext3，可能会遇到这类问题，所以还是大概介绍一下如何解决：

MongoDB按需自动生成数据文件：先是<DB>.0，大小是64M，然后是<DB>.1，大小翻番到128M，到了<DB>.5，大小翻番到2G，其后的数据文件就保持在2G大小。为了避免可能出现的问题，可以采用事先手动创建数据文件的策略：

#!/bin/sh

DB_NAME=$1

cd /path/to/$DB_NAME

for INDEX_NUMBER in {5..50}; do
    FILE_NAME=$DB_NAME.$INDEX_NUMBER

    if [ ! -e $FILE_NAME ]; then
        head -c 2146435072 /dev/zero > $FILE_NAME
    fi
done

注：数值2146435072并不是标准的2G，这是INT整数范围决定的。

…

最后一个求助方式就是官方论坛了，那里的国际友人建议我检查一下是不是索引不佳所致，死马当活马医，我激活了Profiler记录慢操作：

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

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

mongo> use <DB>
mongo> db.system.profile.find().sort({$natural:-1})

…

问题始终没有得到解决，求人不如求己，我又重复了几次迁移旧数据的过程，结果自然还是老样子，但我发现每当出问题的时候，总有一个名叫irqbalance的进程CPU占用率居高不下，搜索了一下，发现很多介绍irqbalance的文章中都提及了NUMA，让我一下子想起之前在日志中看到的警告信息，我勒个去，竟然绕了这么大一个圈圈！安下心来仔细翻阅文档，发现官方其实已经有了相关介绍，按如下设置搞定：

shell> echo 0 > /proc/sys/vm/zone_reclaim_mode
shell> numactl --interleave=all mongod [options]

关于zone_reclaim_mode内核参数的说明，可以参考官方文档。

注：从MongoDB1.9.2开始：MongoDB会在启动时自动设置zone_reclaim_mode。

至于NUMA的含义，简单点说，在有多个物理CPU的架构下，NUMA把内存分为本地和远程，每个物理CPU都有属于自己的本地内存，访问本地内存速度快于访问远程内存，缺省情况下，每个物理CPU只能访问属于自己的本地内存。对于MongoDB这种需要大内存的服务来说就可能造成内存不足，NUMA的详细介绍，可以参考老外的文章。

理论上，MySQL、Redis、Memcached等等都可能会受到NUMA的影响，需要留意。

转自:http://huoding.com/2011/08/09/104

Linux内存管理学习笔记--物理内存分配

每次深入了解一个技术问题，随着挖据的深入，都发现其背后总非常深的背景知识，甚至需要深入到很多底层系统，这个过程有时会让自己迷失，会让自己忘了当初的目的。

在前篇中介绍系统启动时内存的使用情况，本篇将介绍简要Linux如何接管主机的物理内存、组织内存，最后会较为详细的介绍Linux分配内存的一段代码。

前面说了，Linux MM系统细节非常多，自己在探究的时候，也是尝试尽量抓住主线，这里也只能抽取了一些“主线剧情”介绍，其中还可以扩展出很多细节，看客感兴趣可以自己深究，后续如果兴趣还在，我也还会继续写出来。内核版本如果没有特别说明，就是使用2.6.33版本。

1. 物理内存组织

先声明一下，这里说的Linux都是运行Intel X86架构的。从80386开始，为了更好支持内存管理、虚拟内存技术，x86架构开始支持处理器的分页模式（分页是基于分段）。系统将内存分为一个个固定大小的块，称作“page frames”，x86架构每一个“page frames”大小为4096字节。Linux中使用struct page结构来描述一个“page frames”【链接中给出了2.6.18内核下的Page结构】，一个Page结构对应了一个物理内存页。

在Linux中，所有的struct page对象都放在一个数组mem_map，mem_map每一个元素对应一个Page。

2. NUMA下的内存结构

在NUMA架构下，系统根据CPU的物理颗数，将内存分成对应的Node。例如，两颗物理CPU，16GB内存的硬件：系统则将内存分成两个8GB，分别分配给两颗CPU：

my111.cm3:/root>#numactl --hardware
available: 2 nodes (0-1)
node 0 size: 8065 MB
node 1 size: 8080 MB

每一个Node，系统又将其分为多个Zone，64位x86架构下（参考:8.1.5），分为两个ZONE_DMA（低16MB，）、ZONE_NORMAL（其余内存）。所以NUMA架构下的内存分配，也就是在各个zone分配内存。

3. 内存分配函数栈

从底层系统的角度，内存分配有如下函数（这里介绍的底层函数，和上层函数的关系，以后再介绍）：

这里来调查一下函数alloc_pages都做了些什么，都调用了哪些函数：

free_area是一个底层保存空闲内存页的数组，有着特殊的结构，它也是内存分配Buddy system的核心变量。

4. get_page_from_freelist和zone_reclaim_mode

上面函数get_page_from_freelist【mm/page_alloc.c】通过遍历系统中各个zone，来寻找可用内存，根据Linux系统中zone_reclaim_mode的设置不同，遍历时的行为略有不同。zone_reclaim_mode是Linux中的一个可配置参数，为了解该参数如何影响内存分配，那就打开get_page_from_freelist的代码，仔细看看遍历各个zone的流程：

上面看到，zone_reclaim_mode非零时，如果某个zone内存不够，则会尝试出发一次内存回收工作（zone_reclaim），等于零时，则直接尝试写一个zone。

上面是2.6.33内核的代码流程图，2.6.18（RHEL5.4的内核）中则因为没有zcl相对简单一些：

流程图中可以看到，zone_reclaim_mode非零时，get_page_from_freelist【mm/page_alloc.c】函数中会调用zone_watermark_ok扫描free_area，如果当面有没有足够的可用内存，就会调用zone_reclaim【mm/vmscan.c】函数回收内存，zone_reclaim实际调用zone_reclaim【mm/vmscan.】收回内存。

最后

每次深入了解一个技术问题，随着挖据的深入，都发现其背后总非常深的背景知识，甚至需要深入到很多底层系统，这个过程有时会让自己迷失，会让自己忘了当初的目的。如果是Linux方面的技术问题，一般最后会收缩到“体系结构”、“Linux原理”和“算法”，这恰恰对应了计算机系考研时候的三门课程：体系结构、操作系统、和数据结构

参考：

Managing physical memory

Understanding the Linux Kernel, 3rd Edition

转自: http://www.orczhou.com/index.php/2011/02/linux-memory-management-3/