mongodb性能参数

mongodb系统性能相关参数

数据库系统都是相通的,许多系统配置都会影响Mongdodb运行时的性能。

本文档适用于mongodb 3.0版本

Mongodb系统设置

1、  journal：

commitIntervalMs：100 or 30

描述：mongod进程提交journal日志的时间间隔，即fsync的间隔。考虑到磁盘性能，mongod间歇性的flush日志数据；此值越小，数据丢失的可能性越低，磁盘消耗越大，性能越低。如果journal和data file在单一块设备上（如物理卷、raid设备等），日志刷新间隔设置100即可。如果在不同块设备上可设置30毫秒。如果希望write操作强制立即写入journal，可设置参数j:true(在客户端write操作中指定也可)。只对mongod有效，单位：毫秒

Enabled：true or false

性能优先，可考虑不使用journal Enabled选项设置false

2、  wiredTiger：

   engineConfig:

cacheSizeGB：wiredTiger缓存工资及数据的内存大小，单位GB，此值决定了wiredTiger与mmapv1的内存模型不同，它可以现在mongod对内存的使用量，而mmapv1依赖于系统级。默认是设置最大内存的一半，前提是当前只运行一个mongod。

 3、collectionConfig:

        blockCompressor: snappy

        collection数据压缩算法，可选值none、snappy、zlib，默认snappy。Snappy提供了低比例压缩损失一点性能，而zlib提供了更好的压缩性能有更大的损耗，在性能与空间上做选择。如果因为某些原因要修改次参数，mongod已经存在数据，修改此值不会带来问题，旧数据扔然使用原来的算法解压，新数据文件将会采取新的解压缩算法

 4、indexConfig:

        prefixCompression:true

     是否对索引数据使用前缀压缩（prefix compression算法），前缀压缩，对那些经过排序的值存蓄，有很大帮助，可有效的减少索引数据的内存使用量。默认值为true

 

linux 系统设置

1、  操作系统

64位linux系统运行mongodb的最好选择，centos系统推荐使用centos6.2以上版本系统，内核版本2.6.32以上linux系统

 

2、文件系统

 Mongodb会预分配数据文件，并且这些文件都非常大，因此最好使用ext4或XFS。ext4要求内核版本至少为2.6.23，使用XFS要求内核版本至少为2.6.25.

 

3、关闭数据文件所在磁盘分区上的atime

  系统默认记录文件最后被访问的时间。数据库系统如果数据文件都比较频繁，禁止记录这一时间，则会得到性能上的提升。Linux系统，修改/etc/fstab里数据文件所在目录，避免影响其他软件或备份工具的使用如mutt，修改完毕后，重新挂载生效。

修改后如下：

LABEL=/my       /my             ext4    noatime,nodiratime        1 2

重新挂载

mount -o remount /my/

4、不使用hugepages

 cat/proc/sys/vm/nr_hugepages

确保其值为零，如果不是请修改执行下面操作。

 echo 0>/proc/sys/vm/nr_hugepages

设置下次重启后生效，添加如下内容到/etc/sysctl.conf文件里

#sysctl vm.nr_hugepages

vm.nr_hugepages=0

5、禁用NUMA

 可以在BIOS里禁用NUMA，这种方式需要重启系统。另外还可以只对mongodb禁用，推荐使用这种方式

Numactl启动mongod

Numactl –interleave=all /usr/bin/local/mongod

可以把启动项放在脚本里

另外禁用zone_reclaim_mode选项。

确保/proc/sys/vm/zone_reclaim_mode为0，否则执行

#echo 0 >/proc/sys/vm/zone_reclaim_mode

无需重启mongod即可生效

6、设置时钟同步，确保系统时间准确性

 

7、交换空间swap

应分配小的交换空间，以防系统内存使用过多，应控制mongodb尽量不使用或少使用swap，而尽量去使用内存。当系统因某些原因请求内存时，这部分内存内容会被刷新到磁盘中，然后原内存则被替换成其他内容。数据库系统数据不应该被写入交换空间，因为应首先刷新到磁盘。

  数据库系统是一项IO密集性操作。如果swap设置过大，且被大量使用，swap交换的操作本身是磁盘IO的操作，这样会大大影响io负载，影响数据库性能。如果只有一个交换区，系统等待会更加明显，效率很低。这种现象通过性能监视工具很容易发现，cpu不慢，系统却很慢，瓶颈在IO上，swap被过度使用。

  虽然我们也会给swap设置一定的大小，来防止因内存耗尽而导致宕机风险。我们也可以通过设置vm.swappiness = 0来控制当内存不足时，数据库系统做选择，尽量少使用swap。

修改添加vm.swappiness=0到/etc/sysctl.conf

 vm.swappiness=0

8、磁盘存储

尽量使用raid10,在性能和安全性两方面兼顾。根据业务重要性,也可以考虑使用ssd。

不使用NFS远程文件系统

9、设置较少的磁盘预读readahead参数值，32kB或16kB都比较合适

 查看当前值

blockdev --getra /dev/sdb

设置成32KB，单位为扇区大小，一个扇区512字节，64即为32KB。

blockdev --setra 64 /dev/sdb

选择合理的预读值，可以降低内存的使用，特别内存资源不足时。

10、选择一种磁盘调度算法

  Linux io系统目前四种调度算法

as(anticipatory)预期算法

cfq(complete Fairness Queueing)完全公平队列

算法主要目标是在触发i/O请求的所有进程中确保磁盘i/o带宽的公平分配。为了达到这个目标，算法使用许多个排序队列—缺省为64.他们存放了不同进程发出的请求。当算法处理一个请求时，内核调用一个散列函数将当前进程的线程组标识符（PID）；然后，算法将一个新的请求插入到该队列的末尾。因此，同一个进程发出的请求通常被插入相同的队列中。

算法本质上采用轮询方式扫描I/O输入队列，选择第一个非空队列，依次调度不同队列中待定个数（公平）的请求，然后将这些请求移动到调度队列的末尾。

Deadline最后期限

为了避免写请求饿死而设计。

noop(No Operation)

最简单的I/O调度算法。该算法仅适当合并用户请求，并不排序请求：新的请求通常被插在调度队列的开头或末尾，下一个要处理的请求总是队列中的第一个请求。这种算法是为不需要寻道的块设备设计的，如ssd。

具体使用哪种算法通过内核参数elevator指定。大部分算法都很很多的运作，具体到某些方面还是有些建议性方案

  在虚拟化环境以及固态磁盘上，noop算法是一个不错的选择。该调度算法可基本上以最快的速度把操作传递给下层的磁盘控制器，然后让真正的磁盘控制器来处理所需的重新排序问题

  数据库系统中，deadline算法是一个不错的选择

 

11、修改软硬限制

ulimit -n 64000
ulimit -u 32000
该修改仅在当前会话期内有效，为了在下次登录或重启后仍然有效，添加如下内容到“/etc/security/limits.conf”文件。
* soft nofile 64000
* hard nofile 64000
* soft nproc 32000
* hard nproc 32000
12 、cpu

Mongodb对cpu的负载很轻，如果在cpu和内存之间选择，那就选择大内存