四个方面进行 cpu/io 方面的优化处理:
1.集群架构上进行读写分离。所有查询优先考虑在从库上读取,写操作在主库上执行。避免主库混合读写压力过大,也减少主库上读写记录的锁冲突。
connection string中readPreference 设置成secondarypreferred,C++ 驱动版本升级为3.1.3 mongo-cxx-driver(驱动升级,读写分离才生效) 。
2.热表msg_traces 索引优化
针对该慢查询创建联合索引 {"_id": 1, "account": 1, "app_key": 1, "s_pc": 1}。
3.mongodb 历史数据归档和删除
和开发同事沟通,根据实际业务需求,保留msgs、msg_traces 集合中一年左右的文档。在timestamp 字段上创建TTL索引。设置文档的过期时间为 3153600秒(365*24*3600)。
db.msgs.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )
db.msg_traces.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )
mongodb TTL索引将每隔60秒对过期数据执行一次删除操作。删除操作的持续实际取决于mongod 实例的负载。
4 .journal 日志的 commitIntervalMs 参数调整。
从默认的100ms调大到500ms。
目前通过读写分离和索引优化之后,原来分片1在业务高峰期间的cpu load 值由最高值250降低到5以内,优化效果非常明显。
mongodb 分片集群优化思路总结:
分片集群中出现某个分片负载特别高的情况。(往往是某个分片负载高,如果是多个分片节点负载都高,则需要逐个进行分析)
第一步:
首先通过top、iostat、vmstat、mongostat 等工具了解系统大致并发负载和读写比例,观察系统具体瓶颈所在。
第二步:
如果负载只是集中出现在某一个节点上,则通过 mongotop 工具先分析该mongodb实例的热点表是哪些并记录下来。
第三步:
通过 mlogfilter / mloginfo 工具分析业务高峰期间出现的TOP10 慢查询。
第四步:
定位需要优化的目标表,并进行查询优化。
通常第二步和第三步会出现很多相同的表。因为热点数据表和慢查询表往往存在相同的一些表。这些表就是我们需要优化的目标。
mongodb 分片表的优化大致从以下几方面着手:
1.查看表分片键、数据分布、数据总量、数据占用空间等信息。着重看数据分片键设置是否合理、数据分布是否均匀;
2.mloginfo 工具打印出来的慢查询信息中有每个慢查询的查询条件。确认慢查询表上是否有合适的索引满足查询条件执行。需要结合explain() 分析慢查询的具体执行计划。
3.选取业务高峰阶段的mongodb实例原始日志,搜索慢查询表相关的原始查询语句。记录这些原始查询语句,方便后续与开发同事沟通,看能否从业务场景上进行相应的优化。
4.对于日志、事件、会话信息等日志类型的表,可以按照业务需求,根据事件字段,只保留一定时间内的有效数据。通常这要与开发业务
沟通清楚。确认保留时间后,可以利用mongodb TTL索引特性,在特定时间字段上创建索引,设置记录过期时限。
第五步:
架构上做读写分离优化
如果在第三步找出来的 TOP10 慢查询不少是能有效利用索引的简单查询,正常情况下,执行应该很快(200ms之内)。
则需要考虑在架构上做读写分离的优化。因为热点表高并发的读写会让cpu 忙不过来,导致原本正常的查询都出现阻塞。
总之,mongodb 优化关键之处是找出系统瓶颈和问题根源。定位出需要优化的目标表后,简单地加个索引或者做个读写分离,性能问题往往就迎刃而解。
这个和医生看病颇为相似,通过望闻问切和各种医疗检验设备所反馈的数据和报告,再依据丰富的临床经验诊断出病因所在。找出病因后,开什么方子用什么药就是水到渠成的事了。当然,医生看病比给数据库做性能诊断复杂多了,误诊几率也不小。而且,数据库性能优化没找准原因还有不少试错的机会,但是医生试错成本就比较高了。所以当个好医生貌似比做个好DBA更难!
以上插了些题外话。优化上过程中,也需要和开发同事保持有效沟通。当我们理解慢查询产生的业务场景后,有时让开发同事配合做个简单的功能优化,头痛的性能问题也能随之解决。