MongoDB CPU 利用率高，怎么破？

更多深度文章,请关注云计算频道：https://yq.aliyun.com/cloud

经常有用户咨询「MongoDB CPU 利用率很高,都快跑满了」,应该怎么办?

遇到这个问题,99.9999% 的可能性是「用户使用上不合理导致」,本文主要介绍从应用的角度如何排查 MongoDB CPU 利用率高的问题

Step1: 分析数据库正在执行的哀求

用户可以通过 Mongo Shell 连接,并执行 db.currentOp() 命令,能看到数据库当前正在执行的操作,如下是该命令的一个输出示例,标识一个正在执行的操作.重点关注几个字段

• client：哀求是由哪个客户端发起的?

• opid：操作的opid,有必要的话,可以通过 db.killOp(opid) 直接干掉的操作

• secs_running/microsecs_running： 这个值重点关注,代表哀求运行的时间,如果这个值特别大,就得注意了,看看哀求是否合理

• query/ns: 这个能看出是对哪个集合正在执行什么操作

• lock*：还有一些跟锁相关的参数,必要了解可以看官网文档,本文不做详细介绍

db.currentOp 文档在这里,多看官网文档

 { "desc" : "conn632530","threadId" : "140298196924160","connectionId" : 632530,"client" : "11.192.159.236:57052","active" : true,"opid" : 1008837885,"secs_running" : 0,"microsecs_running" : NumberLong(70),"op" : "update","ns" : "mygame.players","query" : { "uid" : NumberLong(31577677)

这里先要明确一下,通过 db.currentOp() 查看正在执行的操作,目的到底是什么?

并不是说我们要将正在执行的操作都列出来,然后通过 killOp 逐个干掉；这一步的目的是要看一下,是否有「意料之外」的耗时哀求正在执行.

好比你的业务平时 CPU 利用率不高,运维管理人员连到数据库执行了一些需要全表扫描的操作,然后突然 CPU 利用率飙高,导致你的业务响应很慢,那么就要重点关注下那些执行时间很长的操作.

一旦找到罪魁祸首,拿到对应哀求的 opid,执行 db.killOp(opid) 将对应的哀求干掉.

如果你的应用一上线,cpu利用率就很高,而且一直持续,通过 db.currentOp 的结果也没发现什么异常哀求,可以进入到 Step2 进行更深入的分析.

Step2：分析数据库慢哀求

MongoDB 支持 profiling 功能,将哀求的执行情况记录到同DB下的 system.profile 集合里,profiling 有3种模式

profiling 设置文档在这里,多看官网文档

• 关闭 profiling

• 针对所有哀求开启 profiling,将所有哀求的执行都记录到 system.profile 集合

• 针对慢哀求 profiling,将超过一定阈值的哀求,记录到system.profile 集合

默认哀求下,MongoDB 的 profiling 功能是关闭,生产环境建议开启,慢哀求阈值可根据需要定制,如不确定,直接使用默认值100ms.

operationProfiling： mode: slowOp

基于上述配置,MongoDB 会将超过 100ms 的哀求记录到对应DB 的 system.profile 集合里,system.profile 默认是一个最多占用 1MB 空间的 capped collection.

查看最近3条 慢哀求,{$natrual: -1} 代表按插入数序逆序

在开启了慢哀求 profiling 的情况下(MongoDB 云数据库是默认开启慢哀求 profiling的),我们对慢哀求的内容进行分析,来找出可优化的点,常见的包括.

profiling的结果输出含义在这里,多看官网文档

CPU杀手1：全表扫描

全集合(表)扫描 COLLSCAN,当一个查询(或更新、删除)哀求需要全表扫描时,是非常耗CPU资源的,所以当你在 system.profile 集合 或者 日志文件发现 COLLSCAN 关键字时,很可能就是这些查询吃掉了你的 CPU 资源；确认一下,如果这种哀求比较频繁,最好是针对查询的字段建立索引来优化.

一个查询扫描了多少文档,可查看 system.profile 里的 docsExamined 的值,该值越大,哀求CPU开销越大.

关键字：COLLSCAN、 docsExamined

CPU杀手2：不合理的索引

有的时候,哀求即使查询走了索引,执行也很慢,通常是因为合理建立不太合理(或者是匹配的结果本身就很多,这样即使走索引,哀求开销也不会优化很多).

如下所示,假设某个集合的数据,x字段的取值很少(假设只有1、2),而y字段的取值很丰富.

{ x: 1,y: 1 }

要服务 {x: 1: y: 2} 这样的查询

db.createIndex( {x: 1} ) 效果欠好,因为x相同取值太多db.createIndex( {x: 1,y: 1} ) 效果欠好,因为x相同取值太多db.createIndex( {y: 1 } ) 效果好,因为y相同取值很少db.createIndex( {y: 1,x: 1 } ) 效果好,因为y相同取值少

至于{y: 1} 与 {y: 1,x: 1} 的区别,可参考MongoDB索引原理 及 复合索引官方文档 自行理解.

一个走索引的查询,扫描了多少条索引,可查看 system.profile 里的 keysExamined 字段,CPU 开销越大.

关键字：IXSCAN、keysExamined

CPU杀手3：大量数据排序

当查询哀求里包含排序的时候,如果排序无法通过索引满足,MongoDB 会在内存李结果进行排序,而排序这个动作本身是非常耗 CPU 资源的,优化的方法仍然是建立索引,对经常需要排序的字段,建立索引.

当你在 system.profile 集合 或者 日志文件发现 SORT 关键字时,就可以考虑通过索引来优化排序.当哀求包含排序阶段时,system.profile 里的 hasSortStage 字段会为 true.

关键字：SORT、hasSortStage

其他还有诸如建索引,aggregationv等操作也可能非常耗 CPU 资源,但本色上也是上述几种场景；建索引需要全表扫描,而vaggeregation 也是遍历、查询、更新、排序等动作的组合.

Step3: 服务才能评估

经过上述2步,你发现整个数据库的查询非常合理,所有的哀求都是高效的走了索引,基本没有优化的空间了,那么很可能是你机器的服务能力已经达到上限了,应该升级配置了(或者通过 sharding 扩展).

当然最好的情况时,提前对 MongoDB 进行测试,了解在你的场景下,对应的服务才能上限,以便及时扩容、升级,而不是到 CPU 资源用满,业务已经完全撑不住的时候才去做评估.