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 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设置一定的大小，来防止因内存耗尽而导致宕机风险。我们也可以通过设置 = 0来控制当内存不足时，数据库系统做选择，尽量少使用swap。
修改添加=0到/etc/
=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/”文件。
* soft nofile 64000
* hard nofile 64000
* soft nproc 32000
* hard nproc 32000
12 、cpu
Mongodb对cpu的负载很轻，如果在cpu和内存之间选择，那就选择大内存