mongodb性能优化

1,修改mongodb最大连接数
 a,ulimit -n 20000
 b，./mongod --dbpath=/var/lib/mongo --fork --logpath=/var/log/mongodb/mongod.log --master  --maxConns=20000
2，mongostat是mongdb自带的状态检测工具
[root@localhost bin]# ./mongostat
insert query update delete getmore command flushes mapped vsize    res faults qr|qw ar|aw netIn netOut conn     time
    *0    *0     *0     *0       0     1|0       0   4.4G  9.2G 100.0M      0   0|0   0|0   79b    10k   18 16:24:34
    *0    *0     *0     *0       0     3|0       0   4.4G  9.2G 100.0M      0   0|0   0|0  196b    11k   18 16:24:35
    *0    *0     *0     *0       0     1|0       0   4.4G  9.2G 100.0M      0   0|0   0|0   79b    10k   18 16:24:36
    *0    *0     *0     *0       0     1|0       0   4.4G  9.2G 100.0M      0   0|0   0|0   79b    10k   18 16:24:37
    *0    *0     *0     *0       0     2|0       0   4.4G  9.2G 100.0M      0   0|0   0|0  133b    10k   18 16:24:38
    *0    *0     *0     *0       0     4|0       0   4.4G  9.2G 100.0M      0   0|0   0|0  250b    11k   18 16:24:39
    *0    *0     *0     *0       0     3|0       0   4.4G  9.2G 100.0M      0   0|0   0|0  196b    11k   18 16:24:40
    *0    *0     *0     *0       0     4|0       0   4.4G  9.2G 100.0M      0   0|0   0|0  250b    11k   18 16:24:41


mongostat命令输出参数解释：
            inserts/s 每秒插入次数
            query/s 每秒查询次数
            update/s 每秒更新次数
            delete/s 每秒删除次数
            getmore/s 每秒执行getmore次数
            command/s 每秒的命令数，比以上插入、查找、更新、删除的综合还多，还统计了别的命令
            flushs/s 每秒执行fsync将数据写入硬盘的次数。一般都是0，或者1，通过计算两个1之间的间隔时间，可以大致了解多长时间flush一次。flush开销是很大的，如果频繁的flush，可能就要找找原因了。
            mapped/s 所有的被mmap的数据量，单位是MB，
            vsize 虚拟内存使用量，单位MB
            res 物理内存使用量，单位MB
          这个和用top看到的一样，mapped, vsize一般不会有大的变动， res会慢慢的上升，如果res经常突然下降，去查查是否有别的程序狂吃内存。
            faults/s 每秒访问失败数（只有Linux有），数据被交换出物理内存，放到swap。不要超过100，否则就是机器内存太小，造成频繁swap写入。此时要升级内存或者扩展。压力下这个数值往往不为0。如果经常不为0，那就该加内存了。
            locked % 被锁的时间百分比，尽量控制在50%以下吧。
            idx miss % 索引不命中所占百分比。如果太高的话就要考虑索引是不是少了
            q t|r|w 当Mongodb接收到太多的命令而数据库被锁住无法执行完成，它会将命令加入队列。这一栏显示了总共、读、写3个队列的长度，都为0的话表示mongo毫无压力。高并发时，一般队列值会升高。
            conn 当前连接数
            time 时间戳




3，获取服务器的状态
> db.serverStatus()
{
	"host" : "localhost.localdomain",
	"version" : "3.0.4-rc0",
	"process" : "mongod",
	"pid" : NumberLong(30851),
	"uptime" : 1377,
	"uptimeMillis" : NumberLong(1376852),
	"uptimeEstimate" : 1356,
	
4，获取当前数据库的信息，比如Obj总数、数据库总大小、平均Obj大小等
db.stats()


显示信息如下


> db.stats()
{
  "collections" : 3,
  "objects" : 80614,
  "dataSize" : 21069700,
  "storageSize" : 39845376,
  "numExtents" : 9,
  "indexes" : 2,
  "indexSize" : 6012928,
  "ok" : 1
}
其中storage表示的就是数据库的大小，显示出的数字的单位是字节，因此如果需要转换单位为KB需要除以1024


5，查看collection的状态
命令: db.collection.stats()


db.channels.stats()
{
    "ns" : "user.channels",
    "count" : 53409370,
    "size" : 14972217152,
    "avgObjSize" : 280.3294094650433,
    "storageSize" : 20933169056,
    "numExtents" : 30,
    "nindexes" : 3,
    "lastExtentSize" : 2146426864,
    "paddingFactor" : 1.0060000002673208,
    "systemFlags" : 1,
    "userFlags" : 0,
    "totalIndexSize" : 6916577136,
    "indexSizes" : {
        "_id_" : 2258914336,
        "usrID_1" : 2033027808,
        "num_1" : 2624634992
    },
    "ok" : 1
}
 count是记录数量， size是总共的字节数。 avgObjSize是平均的 字节数。


参考：http://www.cnblogs.com/zhuque/archive/2013/03/29/2988577.html
      http://www.cnblogs.com/Amaranthus/p/3721155.html
6，mongotop 查看哪些大量的时间花费在读取和写入数据
[root@localhost bin]# ./mongotop -h "192.168.60.XXX:27017" -u XXX -p XXX --authenticationDatabase=tutong 10
2015-06-24T16:55:50.103+0800	connected to: 192.168.60.XXX:27017


                     ns    total    read    write    2015-06-24T16:56:00+08:00
   admin.system.indexes      0ms     0ms      0ms                             
admin.system.namespaces      0ms     0ms      0ms                             
     admin.system.roles      0ms     0ms      0ms                             
     admin.system.users      0ms     0ms      0ms   


ns：包含数据库命名空间，后者结合了数据库名称和集合。
db：包含数据库的名称。名为 . 的数据库针对全局锁定，而非特定数据库。
total：mongod花费的时间工作在这个命名空间提供总额。 


read：提供了大量的时间，这mongod花费在执行读操作，在此命名空间。 


write：提供这个命名空间进行写操作，这mongod花了大量的时间。


7，
db.currentOp()






Mongodb 的命令一般很快就完成，但是在一台繁忙的机器或者有比较慢的命令时，你可以通过db.currentOp()获取当前正在执行的操作。


在没有负载的机器上，该命令基本上都是返回空的， 在负载很高的情况下，可能意义也不是特别的大


>  db.currentOp()
{ "inprog" : [ ] }
以下是一个有负载的机器上得到的返回值样例：


{ "opid" : "shard3:466404288", "active" : false, "waitingForLock" : false, "op" : "query", "ns" : "sd.usersEmails", "query" : { }, "client_s" : "10.121.13.8:34473", "desc" : "conn" },
字段名字都能自解释。如果你发现一个操作太长，把数据库卡死的话，可以用这个命令杀死他


> db.killOp("shard3:466404288")      


1，mongodb更新操作
db.fs.files.update({"contentType" : ".jpg"},{$set:{"contentType":"image/jpeg"}},false,true)
2，千万级以下的用mysql、千万级以上的用mongodb，亿级以上的用hadoop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>




mongodb磁盘性能调优:
主要是可以通过看
1.可以通过linux下的 vmstat 1 999 ，如果其中si,so数值较大说明内存是不够了，需要加大内存
2. 执行mongostat 命令，如果其中faults值较大，那也说明内存上有问题，因为它的失页中断发生次数太多了导致有很多数据是要从硬盘中换入到内存中
在上述情况下就会有大量的数据需要从硬盘交换到内存中，导致硬盘性能跟不上，直接就导致整个mongodb性能低下。
3.用iostat -x查看，发现目前我们的系统iowait:37.33%，一般在25%以上就会有可能在硬盘上存在性能问题，await值：2069.10，说明应用磁盘队列要等2秒以上，等待的时间太长了，说明硬盘上明显存在性能问题。同时svctm值超过15，util值100%，这样就说明目前时间就耗在硬盘上了。
await值的大小一般取决与svctm的值和I/O队列长度以及I/O请求模式，如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，则表示I/O队列等待太长，系统上运行的应用程序将变慢，此时可以通过更换更快的硬盘来解决问题。
4.用hdparam -tT /dev/sda这样的命令可以得到硬盘的速度报告