Find BottleNeck In MongoDB

Find BottleNeck In MongoDB 分为以下两部分：
 - Find BottleNeck
 - Adjust and Optimize

通过MongoDB监控数据查看节点每秒读取数、执行命令、读写等待队列数、网络吞吐、连接数等指标。
通过该性能监控数据可以了解mongodb实例整体连接数、读写请求数及读写比例（有的业务是读请求比重高，有的业务写请求比重较高）。
需要重点关注读写等待队列数量。如果该值超过3或者超过cpu 核数，则代表cpu资源比较吃紧，业务请求已经开始积压。
通过分析MongoDB实时诊断数据，确认请求时间较高的表，根据二八定理，我们可以选择对于占用请求时间超过80%的热表慢查询进行针对性的性能分析和优化。
通过实施诊断数据，查看当前mongodb实例具体执行的慢查询请求。对于聚合分析请求较多业务库，往往不时有超过100秒的聚合分析语句正在执行。导致CPU和IO资源非常紧张。这时为了不影响正常业务的进行，只能暂时选择将很多堆积的慢查询语句先杀掉。

mongodb 分片集群优化思路：

分片集群中出现某个分片负载特别高的情况。（往往是某个分片负载高，如果是多个分片节点负载都高，则需要逐个进行分析）

通常 Part-2 和 Part-3 会出现很多相同的表。因为操作比较频繁和慢查询往往存在相同的一些表。这些表就是我们需要优化的目标。

mongodb 分片优化大致有以下几点：

a. 查看表分片键、数据分布、数据总量、数据占用空间等信息。着重看数据分片键设置是否合理、数据分布是否均匀；

b. 诊断数据中打印出来的慢查询信息中有每个慢查询的查询条件。确认慢查询表上是否有合适的索引满足查询条件执行。需要结合explain() 分析慢查询的具体执行计划。

c. 选取业务高峰阶段的mongodb实例原始日志，过滤慢查询表相关的原始查询语句。记录这些原始查询语句，方便后续与开发同事沟通，看能否从业务场景上进行相应的优化。

d. 对于日志、事件、会话信息等日志类型的表，可以按照业务需求，根据事件字段，只保留一定时间内的有效数据。通常这要与开发业务沟通清楚。确认保留时间后，可以利用mongodb TTL索引特性，在特定时间字段上创建索引，设置记录过期时限。

如果在 Part-3 找出来的 TOP10 慢查询不少是能有效利用索引的简单查询，正常情况下，执行应该很快（200ms之内）。

如果不能解决，则需要考虑在架构上做读写分离的优化。因为热点表高并发的读写会让cpu 忙不过来，导致原本正常的查询都出现阻塞。

总之，mongodb 优化关键之处是找出系统瓶颈和问题根源。定位出需要优化的目标表后，简单地加个索引或者做个读写分离，性能问题往往就迎刃而解。

HowToFindBottleNeckinMongoDB