Mongo性能检查

前几天，公司游戏突然出现大面积无法登录的情况。查看登录服务器的日志发现，一直在提示“Out of semaphores to get db connection”的错误，且CPU、内存的占用很高，磁盘IO达到100%。很明显，一方面是由于Mongo的线程池耗尽了，另一方面就是服务器的能力已经达到了极限，需要重新规划服务器架构。虽然问题最后解决了，但是在此记录一番留作记录，也希望于其他读者有用处。

检查问题方法

检查数据库服务器的CPU、内存、磁盘IO

CPU、内存查看：top
磁盘IO：iostat
用这两个命令，主要是来看看服务器的CPU、内存以及磁盘的使用情况。当时我们的CPU和内存几乎都吃光。

db.stats()、db.serverStatus()

登录数据库服务器，登录mongo，查看数据库的连接池使用情况。当时我们的连接池还是够用的，说明问题并不是这个原因。

mongotop、mongostat

mongotop和mongostat都是随MongoDB一起提供的工具，mongotop能够跟踪并报告一个MongoDB集群当前的读、写活动；mongostat为所有的操作提供了一个全面概览，包括更新、插入的计数，页面错误、索引的丢失情况以及很多其他的关系到系统健康的重要指标。当时我们的数据库执行命令后，发现在查询的时候消耗几分钟甚至更多的时间。说明问题就出在这里。接合当时我们的情况，由于访问的用户很多，一时间并发量太大了，而在登录时是根据用户名和渠道的名称来组合查询，很耗时间，果断在用户名和渠道上组建个索引，顿时查询时间大大缩减。

而至于如果是磁盘的读写负荷过重了的话，则可能需要考虑服务架构的问题，或许是由于本服务器不能承受，需要扩充服务器；或者是程序性能的问题；又或者采用其他架构。

其他一些有用的命令：
db.currentOp() - 显示你所有当前正在运行操作
db.killOp(opid) - 可以用来杀掉长查询
db.collection.stats() - 特定集的状态

解决方法

如果你的应用也出现了这些情况，譬如数据库操作缓慢等，则可以从下面几种情况进行考虑：

1. 服务器本身
   看看服务器本身的硬盘、RAM空间是否够用。

2. 索引
   在使用查询多的地方增加索引的话会起到意想不到的效果。但是，索引也不能太多，多了也可能会影响效率，没必要的就不要添加。

3. 应用程序访问模式没有使用最优的模式设计
   这就是程序的设计问题了，在写程序的时候多多进行压力测试。可能一个人没什么问题，但是如果突然并发量达到几万、几十万则完全不一样了。譬如说可以采用数据库的读写分离。

4. 数据库架构
   有时候一台服务器上可能部署了太多了数据库，这会影响很大的性能。可以将访问量大的数据库拆分出来，单独做成一个数据库服务器。

参考

1. MongoDB运行状态、性能监控，分析
2. 我希望一年前就知道 MongoDB 的那些事儿
3. 为首次部署MongoDB做好准备：容量计划和监控
4. 大规模运行MongoDB应该知道的10件事