(转)mongdb性能优化收集

一、数据库最大连接数问题
当你在后台日志中，发现大量“connection refused because too many open connections: 819”信息时，一般跟你没有设置合适的最大连接数值有关。
默认情况下,在LINUX系统中，MONGODB默认连接数为819,你可以适当调大这个值，但注意这个值不是无限大，最多可设置成20000, 参见MONGODB的官方说明。

我们可以在数据库启动时加--maxConns 10000参数来指定最大连接数
也可以修改mongodb.conf配置文件，在其中加一句maxConns = 10000保存退出后再启动MONGODB就好了。
当然这个问题也跟ulimit限制有关, 可以手动修改ulimit -n 来改动open file 的数目.
如果想使open file的值永久生效的话,请在/etc/security/limits.conf中添加以下四行, 数目根据系统情况具体修改.
*    soft nofile 102400       （*针对所有用户）
*    hard nofile 102400
root soft nofile 102400        （针对ROOT用户）
root hard nofile 102400

然后在/etc/pam.d/login中添加
session    required     /lib64/security/pam_limits.so
....
reboot后即可永久生效.

二、虚拟内存限制问题
MongoDB主从配置后， 启动时报错“ERROR: mmap failed with out of memory”。  这是因为mongodb在设置为主从关系时，会创建“creating replication oplog of size: 944MB”，这个OPLOG日志应该是放在内存中的.
解决方法：
（1）设置oplog的大小，用参数--oplogSize来指定，不默认创建944M
（2）放开虚拟内存的限制（虚拟机默认设定512M ），编辑/etc/profile文件加入ulimit -v unlimited，使用source /etc/profile让设置生效。
再执行主从的启动命令就ok了
mongodb比较吃内存，也可以限制mongodb的内存使用量，操作如下
vi  mongodb.conf
增加 ulimit -m 2560000 (约2.5G 内存)

需要注意的几点：
1. MongoDB在32位操作系统出现“mmap failed with out of memory”错误，这是因为在32位平台中MongoDB不允许数据库文件（累计总和）超过2G，而64位平台没有这个限制。如果在64位平台中也报这个错，一般是虚拟内存不足所致。可以编辑/etc/profile文件加入ulimit -v unlimited，使用source /etc/profile让设置生效或重启生效。

2. oplog的大小和内存没有太大关系，oplogSize相当于mysql数据库的binlog，从库复制的数据都是从oplog也就是local这个库读取的。
--oplopgSize，指定了slave同步时，更新日志保存的最大大小，最新版本的mongodb如果不指定参数的话默认是硬盘空间的5%，如果设置太小，slave同步和主库相差远超过了oplog的大小的话，有可能会数据不一致。

参看官方文档说明：
http://www.mongodb.org/display/DOCS/Replication+Oplog+Length

3、使用mongoDB建议使用高性能sas硬盘，追求性能可以考虑使用raid10硬盘。

三、mongodb占用空间过大的问题

1、空间的预分配：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那样的指数递增，直到2G为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。
2、字段名所占用的空间：为了保持每个记录内的结构信息用于查询，mongodb需要把每个字段的key-value都以BSON的形式存储，如果value域相对于key域并不大，比如存放数值型的数据，则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用空间就小了，但这就要求在易读性与空间占用上作权衡了。建议把字段名作个index，每个字段名用一个字节表示，这样就不用担心字段名取多长了。但这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。
3、删除记录不释放空间：这个很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。

可以定期运行db.repairDatabase()来整理记录释放空间，但这个过程会比较缓慢。

--------------------------
优化系统配置，提升MongoDB性能

许多系统配置都会影响MongoDB运行时的性能，通过优化这些配置，能有效提升MongoDB性能。本文的优化针对Linux系统，实际操作在CentOS 6下完成。文章内容主要来源于MongoDB官方文档，http://docs.mongodb.org/manual/administration/production-notes/，同时结合了笔者的一些实际操作经验。

1、推荐使用2.6.36或以上版本的Linux kernel
笔者使用的CentOS 6.3，默认内核版本仅是2.6.32。由于升级内核影响比较大，此项优化未进行。

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

3、关闭数据文件所在磁盘分区上的atime
Linux下用到文件atime的软件不多，常见的只有mutt。如果你没有使用mutt这样的依赖文件atime时间的软件，建议关闭掉atime。为了减少关闭atime带来的影响，可以只关闭MongoDB 数据文件所在磁盘分区上的atime。
具体操作步骤如下：
1、切换到root身份
su
2、备份当前的fstab文件
cp /etc/fstab /etc/fstab.bak
3、修改fstab文件里数据文件所在分区的挂载属性
修改数据文件所在分区那一行的第四节，在后面附加“noatime,nodiratime”。如果原来是defaults，直接替换掉。
修改前：/dev/mapper/VolGroup-lv_data /data ext4 defaults 1 2
修改后：/dev/mapper/VolGroup-lv_data /data ext4 noatime,nodiratime 1 2
remount该分区，mount -o remount /data/。

4、修改系统限制参数文件描述符数和用户进程数到20000以上。
ulimit -n 64000
ulimit -u 32000
该修改仅在当前会话期内有效，为了在下次登录或重启后仍然有效，添加如下内容到“/etc/security/limits.conf”文件。
* soft nofile 64000
* hard nofile 64000
* soft nproc 32000
* hard nproc 32000
同时，如果你的系统里存在“/etc/security/limits.d/90-nproc.conf”这个文件，注释掉文件里的下面这一行。
#* soft nproc 1024

5、不要使用hugepages
cat /proc/sys/vm/nr_hugepages
查看当前hugepages设置，确保其为0。如果不是，执行下面的操作。
echo 0 > /proc/sys/vm/nr_hugepages
为了让设置在下次重启后有效，添加如下内容到“/etc/sysctl.conf”文件里。
# sysctl vm.nr_hugepages
vm.nr_hugepages = 0

6、禁用NUMA
可以在BIOS里禁用NUMA，这种方式需要重启系统。也可以只针对MongoDB进程禁用，推荐使用这种方式。
具体操作步骤如下：
使用numactl来启动mongod

numactl --interleave=all /usr/bin/local/mongod
确保/proc/sys/vm/zone_reclaim_mode为0，否则执行“echo 0 > /proc/sys/vm/zone_reclaim_mode”，该修改不需要重启mongod。

7、设置较小的磁盘readahead参数值，32KB或16KB都比较合适
查看当前值。

blockdev --getra /dev/sda
设置成32KB，单位为扇区大小，一个扇区512字节，64即为32KB。

blockdev --setra 64 /dev/sda
8、设置时钟同步，确保系统时间准确性
时间准确性对Shard集群尤为重要。安装ntpd服务，并设置为成开机启动。
yum install ntp
chkconfig ntpd on

9、磁盘和存储系统
开启Swap。关于Swap空间，内存为4GB时至少需要2GB，4GB~16GB时至少需要4GB，16GB~64GB时至少需要8GB，64GB~256GB时至少需要16GB。
磁盘阵列使用RAID10，RAID5和RAID6不能提供足够的性能，RAID0写性能不错但读性能较差，应避免使用。成本上允许的话，尽量使用SSD磁盘。
不要使用远程文件系统，比如NFS。