mongodb的监控与性能优化.docx

mongodb的监控与性能优化一、mongodb的监控mongostat是mongdb自带的状态检测工具，在命令行下使用。它会间隔固定时间获取mongodb的当前运行状态，并输出。如果你发现数据库突然变慢或者有其他问题的话，你第一手的操作就考虑采用mongostat命令来查看mongo的状态。它的输出有以下几列： inserts/s 每秒插入次数 query/s 每秒查询次数 update/s 每秒更新次数 delete/s 每秒删除次数 getmore/s 每秒执行getmore次数 command/s 每秒的命令数，比以上插入、查找、更新、删除的综合还多，还统计了别的命令 flushs/s 每秒执行fsync将数据写入硬盘的次数。 mapped/s 所有的被mmap的数据量，单位是MB， vsize 虚拟内存使用量，单位MB res 物理内存使用量，单位MB faults/s 每秒访问失败数（只有Linux有），数据被交换出物理内存，放到swap。不要超过100，否则就是机器内存太小，造成频繁swap写入。此时要升级内存或者扩展 locked % 被锁的时间百分比，尽量控制在50%以下吧 idx miss % 索引不命中所占百分比。如果太高的话就要考虑索引是不是少了 q t|r|w 当Mongodb接收到太多的命令而数据库被锁住无法执行完成，它会将命令加入队列。这一栏显示了总共、读、写3个队列的长度，都为0的话表示mongo毫无压力。高并发时，一般队列值会升高。 conn 当前连接数 time 时间戳 二、mongodb的优化mongodb可以通过profile来监控数据，进行优化。查看当前是否开启profile功能用命令db.getProfilingLevel()返回level等级，值为0|1|2，分别代表意思：0代表关闭，1代表记录慢命令，2代表全部开始profile功能为db.setProfilingLevel(level);#level等级，值同上level为1的时候，慢命令默认值为100ms，更改为db.setProfilingLevel(level,slowms)如db.setProfilingLevel(1,50)这样就更改为50毫秒通过file.find() 查看当前的监控日志。如：Js代码1. file.find(millis:$gt:500) 2. ts:ISODate(2011-07-23T02:50:13.941Z),info:queryorder.orderreslen:11022nscanned:672230nquery:status:1.0nreturned:101bytes:11006640ms,millis:640 3. ts:ISODate(2011-07-23T02:51:00.096Z),info:queryorder.orderreslen:11146nscanned:672302nquery:status:1.0,user.uid:$gt:1663199.0nreturned:101bytes:11130647ms,millis:647 这里值的含义是ts：命令执行时间info：命令的内容query：代表查询order.order： 代表查询的库与集合reslen：返回的结果集大小，byte数nscanned：扫描记录数量nquery：后面是查询条件nreturned：返回记录数及用时millis：所花时间如果发现时间比较长，那么就需要作优化。比如nscanned数很大，或者接近记录总数，那么可能没有用到索引查询。reslen很大，有可能返回没必要的字段。nreturned很大，那么有可能查询的时候没有加限制。官网:/display/DOCS/Database+Profilermongo可以通过db.serverStatus()查看mongod的运行状态Js代码1. db.serverStatus() 2. 3. host:baobao-laptop,#主机名 4. version:1.8.2,#版本号 5. process:mongod,#进程名 6. uptime:15549,#运行时间 7. uptimeEstimate:15351, 8. localTime:ISODate(2011-07-23T06:07:31.220Z),当前时间 9. globalLock: 10. totalTime#总运行时间（ns） 11. lockTime:89206633,#总的锁时间（ns） 12. ratio:0.005737305027178137,#锁比值 13. currentQueue: 14. total:0,#当前需要执行的队列 15. readers:0,#读队列 16. writers:0#写队列 17. , 18. activeClients: 19. total:0,#当前客户端执行的链接数 20. readers:0,#读链接数 21. writers:0#写链接数 22. 23. , 24. mem:#内存情况 25. bits:32,#32位系统 26. resident:337,#占有物理内存数 27. virtual:599,#占有虚拟内存 28. supported:true,#是否支持扩展内存 29. mapped:512 30. , 31. connections: 32. current:2,#当前链接数 33. available:817#可用链接数 34. , 35. extra_info: 36. note:fieldsvarybyplatform, 37. heap_usage_bytes:159008,#堆使用情况字节 38. page_faults:907#页面故作 39. , 40. indexCounters: 41. btree: 42. accesses:59963,#索引被访问数 43. hits:59963,#所以命中数 44. misses:0,#索引偏差数 45. resets:0,#复位数 46. missRatio:0#未命中率 47. 48. , 49. backgroundFlushing: 50. flushes:259,#刷新次数 51. total_ms:3395,#刷新总花费时长 52. average_ms:13.108108108108109,#平均时长 53. last_ms:1,#最后一次时长 54. last_finished:ISODate(2011-07-23T06:07:22.725Z)#最后刷新时间 55. , 56. cursors: 57. totalOpen:0,#打开游标数 58. clientCursors_size:0,#客户端游标大小 59. timedOut:16#超时时间 60. , 61. network: 62. bytesIn:285676177,#输入数据（byte） 63. bytesOut:286564,#输出数据（byte） 64. numRequests:2012348#请求数 65. , 66. opcounters: 67. insert:2010000,#插入操作数 68. query:51,#查询操作数 69. update:5,#更新操作数 70. delete:0,#删除操作数 71. getmore:0,#获取更多的操作数 72. command:148#其他命令操作数 73. , 74. asserts:#各个断言的数量 75. regular:0, 76. warning:0, 77. msg:0, 78. user:2131, 79. rollovers:0 80. , 81. writeBacksQueued:false, 82. ok:1 83. indexCounters:btree:misses 索引的不命中数，和hits的比例高就要考虑索引是否正确建立。需要关心的地方： connections 当前连接和可用连接数，听过一个同行介绍过，mongodb最大处理到2000个连接就不行了（要根据你的机器性能和业务来设定），所以设大了没意义。设个合理值的话，到达这个值mongodb就拒绝新的连接请求，避免被太多的连接拖垮。 indexCounters:btree:misses 索引的不命中数，和hits的比例高就要考虑索引是否正确建立。你看我的”missRatio” : 3.543930204420982e-7，很健康吧。所以miss率在mongostat里面也可以看 其他的都能自解释，也不是查看mongo健康状况的关键，就不说明了。db.stats()查看某一个库的原先状况代码1. db.stats() 2. 3. db:order,#库名 4. collections:4,#集合数 5. objects:2011622,#记录数 6. avgObjSize:111.92214441878245,#每条记录的平均值 7. dataSize:225145048,#记录的总大小 8. storageSize:307323392,#预分配的存储空间 9. numExtents:21,#事件数 10. indexes:1,#索引数 11. indexSize:74187744,#所以大小 12. fileSize:1056702464,#文件大小 13. ok:1 14. 查看集合记录用代码1. db.order.stats() 2. 3. ns:order.order,#命名空间 4. count:2010000,#记录数 5. size:225039600,#大小 6. avgObjSize:111.96, 7. storageSize:307186944, 8. numExtents:18, 9. nindexes:1, 10. lastExtentSize:56089856, 11. paddingFactor:1, 12. flags:1, 13. totalIndexSize:74187744, 14. indexSizes: 15. _id_:74187744#索引为_id_的索引大小 16. , 17. ok:1 18. mongostat命令查看运行中的实时统计，表示每秒实时执行的次数mongodb还提供了一个机遇http的监控页面，可以访问http:/ip:28017来查看，这个页面基本上是对上面的这些命令做了一下综合，所以这里不细述了。根据上面这些监控手段，找到问题后，我们可以进行优化上面找到了某一下慢的命令，现在我们可以通过执行计划跟踪一下，如代码1. db.order.find(status:1.0,user.uid:$gt:2663199.0).explain() 2. 3. cursor:BasicCursor,#游标类型 4. nscanned:2010000,#扫描数量 5. nscannedObjects:2010000,#扫描对象 6. n:337800,#返回数据 7. millis:2838,#耗时 8. nYields:0, 9. nChunkSkips:0, 10. isMultiKey:false, 11. indexOnly:false, 12. indexBounds:#使用索引（这里没有） 13.14. 15. 对于这样的，我们可以创建索引可以通过db.collection.ensureIndex(字段名:1) 来创建索引，1为升序，-1为降序，在已经有多数据的情况下，可用后台来执行，语句db.collection.ensureIndex(字段 名:1 , backgroud:true)获取索引用db.collection.getIndexes() 查看这里我们创建一个user.uid的索引 db.order.ensureIndex(user.uid:1)创建后重新执行代码1. db.order.find(status:1.0,user.uid:$gt:2663199.0).explain() 2. 3. cursor:BtreeCursoruser.uid_1, 4. nscanned:337800, 5. nscannedObjects:337800, 6. n:337800, 7. millis:1371, 8. nYields:0, 9. nChunkSkips:0, 10. isMultiKey:false, 11. indexOnly:false, 12. indexBounds: 13. user.uid: 14. 15. 2663199, 16. 1.7976931348623157e+308 17. 18. 19. 20. 扫描数量减少，速度提高。mongodb的索引设计类似与关系数据库，按索引查找加快书读，但是多了会对写有压力，所以这里就不再叙述了。2.其他优化可以用hint强制索引查找，返回只是需要的数据，对数据分页等。db.currentOp()Mongodb 的命令一般很快就完成，但是在一台繁忙的机器或者有比较慢的命令时，你可以通过db.currentOp()获取当前正在执行的操作。在没有负载的机器上，该命令基本上都是返回空的1db.currentOp()2inprog: 以下是一个有负载的机器上得到的返回值样例：1opid:shard3:466404288,act