MongoDB CPU 利用率高，怎么破？_非关系型数据库

概述介绍《MongoDB CPU 利用率高，怎么破？》开发教程，希望对您有用。

《MongoDB cpu 利用率高，怎么破？》要点：
本文介绍了MongoDB cpu 利用率高，怎么破？，希望对您有用。如果有疑问，可以联系我们。

欢迎参与《MongoDB cpu 利用率高，怎么破？》讨论，分享您的想法，内存溢出PHP学院为您提供专业教程。

更多深度文章,请关注云计算频道：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 开销越大.