MongoDB CPU 利用率高,怎么破?

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
云数据库 Tair(兼容Redis),内存型 2GB
简介: 经常有用户咨询「MongoDB CPU 利用率很高,都快跑满了」,应该怎么办? 遇到这个问题,99.9999% 的可能性是「用户使用上不合理导致」,本文主要介绍从应用的角度如何排查 MongoDB CPU 利用率高的问题 Step1: 分析数据库正在执行的请求 用户可以通过 Mongo Shell 连接,并执行 db.currentOp() 命令,能看到数据库当前正在执行的操作,如下是该命令的一个输出示例,标识一个正在执行的操作。

经常有用户咨询「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)
            },
            "numYields" : 0,
            "locks" : {
                "Global" : "w",
                "Database" : "w",
                "Collection" : "w"
            },
            ....
        },
    

这里先要明确一下,通过 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
  slowOpThresholdMs: 100

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

查看最近3条 慢请求,{$natrual: -1} 代表按插入数序逆序
db.system.profile.find().sort({$natrual: -1}).limit(3)

在开启了慢请求 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 }
{ x: 1, y: 3 }
......
{ x: 1, y: 100000} 
{ x: 2, y: 1 }
{ x: 2, y: 2 }
{ x: 2, y: 3 }
......
{ x: 1, y: 100000} 

要服务 {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 资源用满,业务已经完全撑不住的时候才去做评估。

相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
6月前
|
消息中间件 SQL Kafka
Flink CPU问题之CPU利用率低如何解决
Apache Flink是由Apache软件基金会开发的开源流处理框架,其核心是用Java和Scala编写的分布式流数据流引擎。本合集提供有关Apache Flink相关技术、使用技巧和最佳实践的资源。
|
3月前
|
NoSQL MongoDB 索引
MongoDB 占用CPU资源过高
MongoDB 占用CPU资源过高
44 0
|
5月前
|
Prometheus 监控 Cloud Native
grafana展示的CPU利用率与实际不符的问题探究
观察到`mpstat`命令显示单核CPU的`%usr`和`%sys`分别持续在70%和20%,而Grafana监控数据显示较低。问题源于Grafana表达式计算的是CPU时间增量而非利用率。`mpstat`通过`/proc/stat`获取数据并计算CPU利用率,而`node-exporter`直接导出原始数据。调整Grafana表达式以匹配`mpstat`的计算方式后,两者结果一致。解决方案是修正Grafana查询以准确反映CPU占用率。
231 1
grafana展示的CPU利用率与实际不符的问题探究
|
5月前
|
Python
python3获取内存和cpu利用率记录日志文件psutil
python3获取内存和cpu利用率记录日志文件psutil
65 1
|
6月前
|
监控 Shell
Shell脚本监控CPU、内存和硬盘利用率
Shell脚本监控CPU、内存和硬盘利用率
|
存储 弹性计算 运维
CPU 利用率从 10% 提升至 60%:中型企业云原生成本优化实战指南
在互联网早期迅速发展时,相关领域企业更多注重于扩展业务,为了迅速占领市场,往往会投入较高的成本。然而,随着互联网人口红利逐渐消退,以及近几年的疫情影响,越来越多企业开始重视成本管理,从“粗放式经营”转变为“精细化运营”模式,成本优化成为企业重点关注事项。
609 0
CPU 利用率从 10% 提升至 60%:中型企业云原生成本优化实战指南
|
监控 Shell Perl
监控CPU、内存和硬盘利用率
监控CPU、内存和硬盘利用率
145 1
CPU利用率高又看不到占用率高的进程?
CPU利用率高又看不到占用率高的进程?
169 0
|
Java
[最佳实践] Java线程栈分析 - CPU利用率持续升高
使用应用诊断分析平台ATP的Java线程栈分析功能,诊断CPU利用率持续升高问题
345 0
[最佳实践] Java线程栈分析 - CPU利用率持续升高
|
Cloud Native Linux 应用服务中间件
助力Koordinator云原生单机混部,龙蜥混部技术提升CPU利用率达60%|龙蜥技术
龙蜥社区的三大原生技术为 Koordinator 社区提供了强大的 CPU 混部底层技术支持。
助力Koordinator云原生单机混部,龙蜥混部技术提升CPU利用率达60%|龙蜥技术

相关产品

  • 云数据库 MongoDB 版