(转)部署MongoDB时需要注意的调参

部署MongoDB的生产服务器，给出如下相关建议：

• 使用虚拟化环境；
• 系统配置

1）推荐RAID配置

RAID(Redundant Array of Independent Disk，独立磁盘冗余阵列)是一种可以让我们把多块磁盘当做单独一块磁盘来使用的技术。可使用它来提高磁盘的可靠性或者性能，或二者兼有。一组使用RAID技术的磁盘被称作RAID磁盘阵列。

RAID根据性能的不同，存在着多种配置方式，通常兼顾了速度与容错性。下列是几种最常见的配置方式：

• RAID0 
  使用磁盘分割技术(disk striping)将多个磁盘并列起来以提升性能。每块磁盘保存一部分数据，与mongodb中的分片类似。由于存在多个底层磁盘，因此大量数据可在同一时间写入磁盘内。然而，如果其中一块磁盘发生故障导致数据丢失，则这些数据不会存在备份，这也会导致读取速度变慢(尤其是在Amazon 的Elastic Block Store 服务上)，
  因为一些数据卷可能比另一些要慢。
• RAID1
  使用镜像来提高可靠性。同样的数据副本会被写入到阵列的每一个成员当中。这一方法的性能要比RAID0低，因为阵列中的一个速度慢的成员会拖慢整个阵列的写入速度。然而，如果其中一块磁盘发生故障，还可以在阵列中的其他成员上找到数据副本。
• RAID5
  在使用磁盘分割技术的基础上，额外存储数据的校验信息，以防服务器故障导致数据丢失。一般情况下，一块磁盘发生故障时RAID5可以自动处理它，用户并不会感觉到发生故障。然而，这也使得RAID5 成为这些RAID配置方案中最慢的一种，因为它需要在写入数据时计算校验信息。而mongodb所进行的恰恰是典型的多次少量的数据写入工作，因此使用RAID5所带来的代价尤为可观。
• RAID10
  RAID10是一种RAID0和RAID1的组合：数据被分割以提升速度，又被复制镜像以提高可靠性。

推荐使用RAID10，它比RAID0更安全，也能解决RAID1的性能问题。在副本集的基础上，再使用RAID1有些浪费，从而可选择RAID0。

不要用RAID5，它会非常非常慢。

2）虚拟化

a）禁止内存过度分配

内存过度分配（memory overcommitting）的设置值决定了当进程向操作系统请求过度内存是应采取的策略。基于这一设置，内核可能会为进程分配内存，哪怕那些内存当前是不可用的(期望的结果是，当进程用到这段内存时它已变为可用的)。这种内核向进程许诺不存在的内存的行为，就叫做内存过度分配。这一特性使得Mongodb无法很好的运作。

vm.overcomit_memory的值可能为0（让内核来猜测过度分配的大小），可能为1（满足所有内存分配请求），可能为2（分配的虚拟地址空间最多不超过交换空间与一小部分过度分配的和）。将此值设为2所代表的意义最为复杂，同时也是最佳选择。运行以下命令将此值设为2：

$ echo 2>/proc/sys/vm/overcommit_memory

更改这一设置后，无需重启Mongodb.

在此目录下，/proc/sys/vm/overcommit_memory

该文件指定了内核针对内存分配的策略，其值可以是0、1、2。

0，   表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。

1，   表示内核允许分配所有的物理内存，而不管当前的内存状态如何。

2，   表示内核允许分配超过所有物理内存和交换空间总和的内存（参照overcommit_ratio）。

缺省设置：0

3) 在查阅文档中，对Linux下proc里关于磁盘性能的参数有涉及，如下：

mongodb的mmap不调用fsync强刷到磁盘，操作系统也是会帮我们自动刷到磁盘的，linux有个dirty_writeback_centisecs参数用于定义脏数据在内存停留的时间（默认为500，即5秒），过了这个timeout时间就会被系统刷到磁盘上。在这个自动刷的过程中是会阻塞所有的IO操作的，如果要刷的数据特别多的话，容易产生一些长耗时的操作，例如有些使用mmap的程序每隔一段时间就会出现有超时操作，一般的优化手段是考虑修改系统参数dirty_writeback_centisecs，加快脏页刷写频率来减少长耗时。mongodb是定时强刷，不会有此问题。

在此目录下，/proc/sys/vm/dirty_writeback_centisecs

这个参数控制内核的脏数据刷新进程pdflush的运行间隔。单位是 1/100 秒。缺省数值是500，也就是 5 秒。如果你的系统是持续地写入动作，那么实际上还是降低这个数值比较好，这样可以把尖峰的写操作削平成多次写操作。设置方法如下：

echo "100" > /proc/sys/vm/dirty_writeback_centisecs

如果你的系统是短期地尖峰式的写操作，并且写入数据不大（几十M/次）且内存有比较多富裕，那么应该增大此数值：

echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

4)日志

mongodb默认将日志发送至stdout（标准输出，通常为终端）。大多初始化脚本会使用–logpath选项，将日志发送至文件。如在同一台机器上有多个MongoDB实例（比如说一个mongod和一个mongos），注意保证各实例的日志分别存放在单独的文件中。确保知道的日志的存放位置，并拥有文件的读访问权限。

Mongodb会输出大量的日志消息，但请不要使用 --quiet选项(该选项会隐藏部分日志信息)。保持日志级别为默认值通常不错，此时日志中有足够的信息进行基本调试(如耗时过长或者启动异常的原因等)，但日志占用的空间并不大。调试应用某特定问题时，可使用一些选项从日志中获取更多信息。

首先，在重启Mongodb时，可通过在参数中附加数目更多的“v”（即-v、-vv、-vvv、-vvvv或-vvvvv），或运行如下setParameter命令，完成日志级别（loglevel）的更改。

>db.adminCommand({"setParameter":1,"logLevel":3});

记得将日志级别重设为0，否则日志中会存在过多不必要的内容。可将日志级别调高至5，这时mongod会在日志中记录几乎所有的操作，包括每一个请求所处理的内容。由于mongod将所有内容都写入了日志文件，因此可产生大量的磁盘读写操作（IO），从而拖慢一个忙碌的系统。如需即时看到正在进行的所有操作，打开分析器不失为更好的方法：

MongoDB默认记录耗时超过100毫秒的查询信息。如100毫秒不适用于应用，可通过setProfilingLevel 命令来更改此阈值：

> // 只记录耗时超过500毫秒的查询操作

> db.setProfilingLevel(1,500)

{"was":0,"slowms":100,"ok":1}

>db.setProfilingLevel(0)

{"was":1,"slowms":500,"ok":1}

上述第二条指令将关闭分析器，但第一条指令中以毫秒为单位的值将继续作为所有数据库中日志记录的阈值而生效。也可以用-slowms 选项重启MongoDB来更改这一阈值。

最后，设置一个计划任务以便每天或每周分割（rotate）日志文件。如使用–logpath 选项启动MongoDB，向进程发送一个SIGUSR1 信号即使其对日志进行分割。也可以使用logRotate命令以达到相同目的：

>db.adminCommand({"logRotate":1})

如不是通过 --logpath 选项启动的MongoDB，则不能对日志进行分割。

5） 关闭数据库文件的 atime

禁止系统对文件的访问时间更新会有效提高文件读取的性能。这个可以通过在/etc/fstab 文件中增加 noatime 参数来实现。例如:

/dev/xvdb /data ext4 noatime 0 0

修改完文件后重新 mount就可以:

＃ mount -o remount /data

6）禁止 NUMA

在一个使用NUMA技术的多处理器Linux 系统上，你应该禁止NUMA的使用。MongoDB在NUMA环境下运行性能有时候会可能变慢，特别是在进程负载很高的情况下。