凯发k8国际娱乐官网入口-k8凯发> 文档数据库服务 dds> > 排查dds实例cpu使用率高的问题
更新时间:2023-08-24 gmt 08:00

排查dds实例cpu使用率高的问题-凯发k8国际娱乐官网入口

使用文档数据库服务时,如果您的cpu使用率很高或接近100%,会导致数据读写处理缓慢,从而影响业务正常运行。

本章节帮助您分析数据库正在执行的请求和数据库慢请求,经过分析优化后,使得数据库的查询相对合理,所有的请求都高效使用了索引,从而排查文档数据库服务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 ,系统自动将请求时间超过100ms的执行情况记录到对应数据库下的“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进行规格变更或者添加分片数量。具体操作请根据当前的实例类型参考如下文档。
分享:
网站地图