计算
弹性云服务器 ECS
Flexus云服务
裸金属服务器 BMS
弹性伸缩 AS
镜像服务 IMS
专属主机 DeH
函数工作流 FunctionGraph
云手机服务器 CPH
Huawei Cloud EulerOS
网络
虚拟私有云 VPC
弹性公网IP EIP
虚拟专用网络 VPN
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
VPC终端节点 VPCEP
云连接 CC
企业路由器 ER
企业交换机 ESW
全球加速 GA
安全与合规
安全技术与应用
Web应用防火墙 WAF
企业主机安全 HSS
云防火墙 CFW
安全云脑 SecMaster
DDoS防护 AAD
数据加密服务 DEW
数据库安全服务 DBSS
云堡垒机 CBH
数据安全中心 DSC
云证书管理服务 CCM
边缘安全 EdgeSec
威胁检测服务 MTD
CDN与智能边缘
内容分发网络 CDN
CloudPond云服务
智能边缘云 IEC
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
迁移中心 MGC
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
云搜索服务 CSS
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
数据治理中心 DataArts Studio
数据可视化 DLV
数据湖工厂 DLF
湖仓构建 LakeFormation
企业应用
云桌面 Workspace
应用与数据集成平台 ROMA Connect
云解析服务 DNS
专属云
专属计算集群 DCC
IoT物联网
IoT物联网
设备接入 IoTDA
智能边缘平台 IEF
用户服务
账号中心
费用中心
成本中心
资源中心
企业管理
工单管理
国际站常见问题
ICP备案
我的凭证
支持计划
客户运营能力
合作伙伴支持计划
专业服务
区块链
区块链服务 BCS
Web3节点引擎服务 NES
解决方案
SAP
高性能计算 HPC
视频
视频直播 Live
视频点播 VOD
媒体处理 MPC
实时音视频 SparkRTC
数字内容生产线 MetaStudio
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
存储容灾服务 SDRS
高性能弹性文件服务 SFS Turbo
弹性文件服务 SFS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属分布式存储服务 DSS
容器
云容器引擎 CCE
容器镜像服务 SWR
应用服务网格 ASM
华为云UCS
云容器实例 CCI
管理与监管
云监控服务 CES
统一身份认证服务 IAM
资源编排服务 RFS
云审计服务 CTS
标签管理服务 TMS
云日志服务 LTS
配置审计 Config
资源访问管理 RAM
消息通知服务 SMN
应用运维管理 AOM
应用性能管理 APM
组织 Organizations
优化顾问 OA
IAM 身份中心
云运维中心 COC
资源治理中心 RGC
应用身份管理服务 OneAccess
数据库
云数据库 RDS
文档数据库服务 DDS
数据管理服务 DAS
数据复制服务 DRS
云数据库 GeminiDB
云数据库 GaussDB
分布式数据库中间件 DDM
数据库和应用迁移 UGO
云数据库 TaurusDB
人工智能
人脸识别服务 FRS
图引擎服务 GES
图像识别 Image
内容审核 Moderation
文字识别 OCR
AI开发平台ModelArts
图像搜索 ImageSearch
对话机器人服务 CBS
华为HiLens
视频智能分析服务 VIAS
语音交互服务 SIS
应用中间件
分布式缓存服务 DCS
API网关 APIG
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
分布式消息服务RocketMQ版
多活高可用服务 MAS
事件网格 EG
企业协同
华为云会议 Meeting
云通信
消息&短信 MSGSMS
云生态
合作伙伴中心
云商店
开发者工具
SDK开发指南
API签名指南
Terraform
华为云命令行工具服务 KooCLI
其他
产品价格详情
系统权限
管理控制台
客户关联华为云合作伙伴须知
消息中心
公共问题
开发与运维
应用管理与运维平台 ServiceStage
软件开发生产线 CodeArts
需求管理 CodeArts Req
部署 CodeArts Deploy
性能测试 CodeArts PerfTest
编译构建 CodeArts Build
流水线 CodeArts Pipeline
制品仓库 CodeArts Artifact
测试计划 CodeArts TestPlan
代码检查 CodeArts Check
代码托管 CodeArts Repo
云应用引擎 CAE
开天aPaaS
云消息服务 KooMessage
云手机服务 KooPhone
云空间服务 KooDrive
文档首页/ 文档数据库服务 DDS/ 用户指南/ 性能调优/ 实例CPU使用率高问题排查

实例CPU使用率高问题排查

更新时间:2023-09-04 GMT+08:00

使用文档数据库服务时,如果您的CPU使用率达到80%,则认为CPU存在瓶颈。此时,会导致数据读写处理缓慢,从而影响业务正常运行。

本章节帮助您分析数据库正在执行的请求和数据库慢请求,经过分析优化后,使得数据库的查询相对合理,所有的请求都高效使用了索引,从而排查文档数据库服务CPU使用率高的问题。

分析DDS数据库正在执行的请求

  1. 通过Mongo Shell连接DDS实例。
  2. 执行以下命令,查看数据库当前正在执行的操作。

    db.currentOp()

    回显如下:

    {
            "raw" : {
                    "shard0001" : {
                            "inprog" : [
                                    {
                                            "desc" : "StatisticsCollector",
                                            "threadId" : "140323686905600",
                                            "active" : true,
                                            "opid" : 9037713,
                                            "op" : "none",
                                            "ns" : "",
                                            "query" : {
     
                                            },
                                            "numYields" : 0,
                                            "locks" : {
     
                                            },
                                            "waitingForLock" : false,
                                            "lockStats" : {
     
                                            }
                                    },
                                    {
                                            "desc" : "conn2607",
                                            "threadId" : "140323415066368",
                                            "connectionId" : 2607,
                                            "client" : "172.16.36.87:37804",
                                            "appName" : "MongoDB Shell",
                                            "active" : true,
                                            "opid" : 9039588,
                                            "secs_running" : 0,
                                            "microsecs_running" : NumberLong(63),
                                            "op" : "command",
                                            "ns" : "admin.",
                                            "query" : {
                                                    "currentOp" : 1
                                       },
                                            "numYields" : 0,
                                            "locks" : {
     
                                            },
                                            "waitingForLock" : false,
                                            "lockStats" : {
     
                                            }
                                    }
                            ],
                            "ok" : 1
                    },
        ...
    }
    说明:
    • client:发起请求的客户端。
    • opid:操作的唯一标识符。
    • secs_running:该操作已经执行的时间,单位:秒。如果该字段返回的值特别大,需要查看请求是否合理。
    • microsecs_running:该操作已经执行的时间,单位:微秒。如果该字段返回的值特别大,需要查看请求是否合理。
    • op:操作类型。通常是query、insert、update、delete、command中的一种。
    • ns:操作目标集合。
    • 其他参数详见db.currentOp()命令官方文档
  3. 根据命令执行结果,分析是否有异常耗时的请求正在执行。

    如果业务日常运行的CPU使用率不高,由于执行某一操作使得CPU使用率过高,导致业务运行缓慢,该场景下,您需要关注执行耗时久的请求。

    如果发现异常请求,您可以找到该请求对应的opid,执行db.killOp(opid)命令终止该请求。

分析DDS数据库的慢请求

文档数据库服务默认开启了慢请求Profiling ,系统自动将请求时间超过500ms的执行情况记录到对应数据库下的“system.profile”集合中。

  1. 通过Mongo Shell连接DDS实例。

    开通公网访问的实例

    未开通公网访问的实例

  2. 执行以下命令,进入指定数据库,以“test”为例。

    use test

  3. 查看是否生成慢sql集合“system.profile”。

    show collections;

    • 回显中有“system.profile”,说明产生了慢SQL,继续执行下一步。
      mongos> show collections
      system.profile
      test
    • 回显中没有“system.profile”,说明未产生慢SQL,该数据库不涉及慢请求分析。
      mongos> show collections
      test
  4. 查看数据下的慢请求日志。

    db.system.profile.find().pretty()

  5. 分析慢请求日志,查找CPU使用率升高的原因。

    下面是某个慢请求日志示例,可查看到该请求进行了全表扫描,扫描了1561632个文档,没有通过索引进行查询。

    {
            "op" : "query",
            "ns" : "taiyiDatabase.taiyiTables$10002e",
            "query" : {
                    "find" : "taiyiTables",
                    "filter" : {
                            "filed19" : NumberLong("852605039766")
                    },
                    "shardVersion" : [
                            Timestamp(1, 1048673),
                            ObjectId("5da43185267ad9c374a72fd5")
                    ],
                    "chunkId" : "10002e"
            },
            "keysExamined" : 0,
            "docsExamined" : 1561632,
            "cursorExhausted" : true,
            "numYield" : 12335,
            "locks" : {
                    "Global" : {
                            "acquireCount" : {
                                    "r" : NumberLong(24672)
                            }
                    },
                    "Database" : {
                            "acquireCount" : {
                                    "r" : NumberLong(12336)
                            }
                    },
                    "Collection" : {
                            "acquireCount" : {
                                    "r" : NumberLong(12336)
                            }
                    }
            },
            "nreturned" : 0,
            "responseLength" : 157,
            "protocol" : "op_command",
            "millis" : 44480,
            "planSummary" : "COLLSCAN",
            "execStats" : {
                  "stage" : "SHARDING_FILTER",                                                                                                                                       [3/1955]
                    "nReturned" : 0,
                    "executionTimeMillisEstimate" : 43701,
                    "works" : 1561634,
                    "advanced" : 0,
                    "needTime" : 1561633,
                    "needYield" : 0,
                    "saveState" : 12335,
                    "restoreState" : 12335,
                    "isEOF" : 1,
                    "invalidates" : 0,
                    "chunkSkips" : 0,
                    "inputStage" : {
                            "stage" : "COLLSCAN",
                            "filter" : {
                                    "filed19" : {
                                            "$eq" : NumberLong("852605039766")
                                    }
                            },
                            "nReturned" : 0,
                            "executionTimeMillisEstimate" : 43590,
                            "works" : 1561634,
                            "advanced" : 0,
                            "needTime" : 1561633,
                            "needYield" : 0,
                            "saveState" : 12335,
                            "restoreState" : 12335,
                            "isEOF" : 1,
                            "invalidates" : 0,
                            "direction" : "forward",
                            "docsExamined" : 1561632
                    }
            },
            "ts" : ISODate("2019-10-14T10:49:52.780Z"),
            "client" : "172.16.36.87",
            "appName" : "MongoDB Shell",
            "allUsers" : [
                    {
                            "user" : "__system",
                            "db" : "local"
                    }
            ],
           "user" : "__system@local"
    }

    在慢请求日志中,您需要重点关注以下关键字。

    • 全集合(全表)扫描:COLLSCAN

      当一个操作请求(如query、update、delete)需要全表扫描时,将大量占用CPU资源。在查看慢请求日志时,发现COLLSCAN关键字,很可能是这些查询占用了CPU资源。

      如果该类操作请求较为频繁,建议您对查询的字段建立索引进行优化。

    • 全集合(全表)扫描:docsExamined

      通过查看参数“docsExamined”的值,可以查看一个查询扫描了多少文档。该值越大,请求的CPU使用率越高。

    • 不合理的索引:IXSCAN、keysExamined
      说明:
      • 索引不是越多越好,过多索引会影响写入和更新的性能。
      • 如果您的应用偏向于写操作,建立索引可能会降低写操作的性能。

      通过查看参数“keysExamined”的值,可以查看一个使用了索引的查询,扫描了多少条索引。该值越大,请求的CPU使用率越高。

      如果索引建立不太合理,或者匹配的结果很多。该场景下,即便使用了索引,请求的CPU使用率也不会降低很多,执行的速度也会很慢。

      示例:对于某个集合的数据,a字段的取值很少(只有1和2),而b字段的取值很多。

      { a: 1, b: 1 }
      { a: 1, b: 2 }
      { a: 1, b: 3 }
      ......
      { a: 1, b: 100000} 
      { a: 2, b: 1 }
      { a: 2, b: 2 }
      { a: 2, b: 3 }
      ......
      { a: 1, y: 100000}

      如下所示,要实现 {a: 1, b: 2} 这样的查询。

      db.createIndex( {a: 1} )         效果不好,因为a相同取值太多
      db.createIndex( {a: 1, b: 1} )   效果不好,因为a相同取值太多
      db.createIndex( {b: 1 } )        效果好,因为b相同取值很少
      db.createIndex( {b: 1, a: 1 } )  效果好,因为b相同取值少

      关于{a: 1}与{b: 1, a: 1}的区别,可参考官方文档

    • 大量数据排序:SORT、hasSortStage

      当查询请求中包含排序时,“system.profile”集合中的参数“hasSortStage”的值为“true”。如果排序无法通过索引实现,将在查询结果中进行排序。由于排序将占用大量CPU资源,该场景下,需要通过对经常排序的字段建立索引进行优化。

      当您在“system.profile”集合中发现SORT关键字时,可以考虑通过索引来优化排序。

    其他操作如建立索引、Aggregation(遍历、查询、更新、排序等动作的组合)也可能占用大量CPU资源,但本质上也适用以上几种场景。更多Profiling的设置,请参见官方文档

分析服务能力

经过前面数据库正在执行的请求和慢请求的分析和优化,所有的请求都使用了合理的索引,CPU的使用率相对趋于稳定。如果经过前面的分析排查,CPU使用率仍然居高不下,则可能是因为当前实例已达到性能瓶颈,不能满足业务需要,此时您可以通过如下方法解决。
  1. 通过查看监控信息分析实例资源的使用情况,详情请参见查看监控指标
  2. 对DDS进行规格变更或者添加分片数量。

我们使用cookie来确保您的高速浏览体验。继续浏览本站,即表示您同意我们使用cookie。 详情

文档反馈

文档反馈

意见反馈

0/500

标记内容

同时提交标记内容