前言

首先,我们简单梳理一下,CPU 在什么情况下才算负载较高?负载查看是通过"uptime"命令查看。大家都知道,命令显示的结果分别表示1分钟、5分钟、15分钟的负载情况,这点就不多做说明。在系统负荷方面,多核CPU与多CPU效果类似,所以考虑系统负荷的时候,必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后,把系统负荷除以总的核心数,只要每个核心的负荷不超过1.0,就表明电脑正常运行。从单棵CPU来说,一般负载不超过0.7都无需关系,当超过该值得时候,就应该开始调查了,问题出在哪里,防止情况恶化。

负载计算公式:

[root@mongodb-1219 ~]# grep 'model name' /proc/cpuinfo | wc -l
24
[root@mongodb-1219 ~]# echo "0.7 * 24" |bc
16.8

N个CPU的电脑,可接受的系统负荷最大为n。正常情况为"N * 0.7",该值为可观状态。

案例

[root@mongodb-1219 ~]# top
top - 09:58:34 up 325 days, 14:15, 5 users, load average: 84.13, 156.16, 108.10
Tasks: 1078 total, 1 running, 1077 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.9 us, 0.2 sy, 0.0 ni, 96.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 32639968 total, 1817952 free, 998372 used, 29823644 buff/cache
KiB Swap: 16777212 total, 16773128 free, 4084 used. 29489896 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
333052 root 20 0 34.607g 657716 262228 S 74.3 2.0 209:12.13 mongod
366752 root 20 0 147216 3128 1432 S 1.0 0.0 0:02.50 top
367511 root 20 0 147072 3024 1416 R 1.0 0.0 0:00.19 top
2189 root 20 0 686788 36396 4188 S 0.3 0.1 267:57.64 salt-minion
1 root 20 0 69856 31864 1964 S 0.0 0.1 15:13.08 systemd

如图所示,该服务器CPU使用高达74%(截图存在一定的偏差,其实此时的用户占用CPU值相当高)。根据信息可以得知,是用户态CPU使用较高,那么这种情况一般都是用户使用不合理。这种情况,不仅在MongoDB中,MySQL中也会有类似的问题。

Setup 1.查看相关日志

查看日志,发现有条查询语句竟然耗时7077ms,看样子有问题。(此时估摸着,就是开发没有加索引。)

Setup 2.分析数据库正在执行的请求

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

  client:请求是由哪个客户端发起的;

  opid:操作的opid,有需要的话,可以通过 db.killOp(opid) 直接干掉的操作;
  secs_running/microsecs_running: 这个值重点关注,代表请求运行的时间,如果这个值特别大,就得注意了,看看请求是否合理;
  query/ns: 这个能看出是对哪个集合正在执行什么操作;
  lock*:还有一些跟锁相关的参数,需要了解可以看官网文档,本文不做详细介绍;

Setup 3.分析数据库的慢请求

MongoDB 支持 profiling 功能,将请求的执行情况记录到同DB下的 system.profile 集合里,profiling 有3种模式:
  关闭 profiling
  针对所有请求开启 profiling,将所有请求的执行都记录到 system.profile 集合
  针对慢请求 profiling,将超过一定阈值的请求,记录到system.profile 集合
  默认请求下,MongoDB 的 profiling 功能是关闭,生产环境建议开启,慢请求阈值可根据需要定制,如不确定,直接使用默认值100ms。

关于profiling功能说明,参考文档。默认请求下,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)

情况1:全盘扫描

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

一个查询扫描了多少文档,可查看 system.profile 里的 docsExamined 的值,该值越大,请求CPU开销越大。关键字:COLLSCAN、 docsExamined。

情况2:索引未添加或不合理

一个走索引的查询,扫描了多少条索引,可查看 system.profile 里的 keysExamined 字段,该值越大,CPU 开销越大。关键字:IXSCAN、keysExamined。

情况3:大量数据排序

当查询请求里包含排序的时候,如果排序无法通过索引满足,MongoDB 会在内存里将结果进行排序,而排序这个动作本身是非常耗 CPU 资源的,优化的方法仍然是建立索引,对经常需要排序的字段,建立索引。当你在 system.profile 集合 或者 日志文件发现 SORT 关键字时,就可以考虑通过索引来优化排序。当请求包含排序阶段时, system.profile 里的 hasSortStage 字段会为 true。关键字:SORT、hasSortStage。

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

基本上就是以上几种情况,还有的话就是MongoDB确实已经达到瓶颈,此时可能需要通过shard来解决。

MongoDB CPU使用较高,如何排查?的更多相关文章

  1. MongoDB CPU利用率很高,怎么破(转)

    经常有用户咨询:MongoDB CPU 利用率很高,都快跑满了,应该怎么办? 遇到这个问题,99.9999% 的可能性是「用户使用上不合理导致」,本文主要介绍从应用的角度如何排查 MongoDB CP ...

  2. linux Java项目CPU内存占用高故障排查

    linux Java项目CPU内存占用高故障排查 top -Hp 进程号 显示进程中每个线程信息,配合jstack定位java线程运行情况 # 线程详情 jstack 线程PID # 查看堆内存中的对 ...

  3. kubelet CPU 使用率过高问题排查

    kubelet CPU 使用率过高问题排查 问题背景 客户的k8s集群环境,发现所有的worker节点的kubelet进程的CPU使用率长时间占用过高,通过pidstat可以看到CPU使用率高达100 ...

  4. 一次java Cpu占用过高的排查

    某一个项目CPU占用率一直很高,经常在40%-50%之间,最近比较闲,就开始了排查工作. 1.通过 jstack命令输出进程的堆栈信息 jstack 2788 >C:\log.txt 将堆栈信息 ...

  5. cpu load过高问题排查

    load average的概念 top命令中load average显示的是最近1分钟.5分钟和15分钟的系统平均负载. 系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少 ...

  6. CPU负载过高异常排查实践与总结

    昨天下午突然收到运维邮件报警,显示数据平台服务器cpu利用率达到了98.94%,而且最近一段时间一直持续在70%以上,看起来像是硬件资源到瓶颈需要扩容了,但仔细思考就会发现咱们的业务系统并不是一个高并 ...

  7. 性能优化-CPU占用过高问题排查

    1. 性能优化是什么? 1.1 性能优化就是发挥机器本来的性能 1.2 性能瓶颈在哪里,木桶效应.   CPU占用过高 1.现象重现 CPU占用过高一般情况是代码中出现了循环调用,最容易出现的情况有几 ...

  8. 机器CPU load过高问题排查

    load average的概念 系统平均负载定义:在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数.如果一个进程满足以下条件则其就会位于运行队列中: 它没有在等待I/O操作 ...

  9. 服务器cpu负载过高问题排查

    https://blog.csdn.net/MrZhangXL/article/details/77711996 第一步 :执行top命令,查出当前机器线程情况 top - 09:14:36 up 1 ...

随机推荐

  1. python编码与存储读取数据(数组字典)

    Camp时在python2的编码上坑了不少. 理解pyhon2的编码 python2字符串类型只有两种: str类型:b'xxx'即是str类型, 是编码后的类型,len()按字节计算 unicode ...

  2. Java线程总结---第一天

    线程和进程各自有什么区别和优劣: 进程是资源分配的最小单位,线程是程序执行的最小单位 进程有自己的独立地址空间,每启动一个进程,系统就会为它分配地址空间,建立数据表来维护代码段.堆栈段和数据段,这种操 ...

  3. 【BZOJ1966】[AHOI2005]病毒检测(动态规划)

    [BZOJ1966][AHOI2005]病毒检测(动态规划) 题面 BZOJ 洛谷 题解 我就蒯了一份代码随便改了改怎么就过了??? 从这道题目蒯的 代码: #include<iostream& ...

  4. 【arc093f】Dark Horse(容斥原理,动态规划,状态压缩)

    [arc093f]Dark Horse(容斥原理,动态规划,状态压缩) 题面 atcoder 有 \(2^n\) 名选手,编号为 \(1\) 至 \(2^n\) .现在这 \(2^n\) 名选手将进行 ...

  5. NOIP2018 No regrets youth

    NOIP2018在即,20181009总结一些易错的知识点和解题方法 ——by ljc20020730 HGOI NOIP2018 No regrets youth ! NOIP2018 No reg ...

  6. 界面编程之QT的事件20180727

    /*******************************************************************************************/ 一.事件 1 ...

  7. 使用开源Breeze工具部署Kubernetes 1.12.1高可用集群

    Breeze项目是深圳睿云智合所开源的Kubernetes图形化部署工具,大大简化了Kubernetes部署的步骤,其最大亮点在于支持全离线环境的部署,且不需要FQ获取Google的相应资源包,尤其适 ...

  8. Scala进阶之路-高级数据类型之集合的使用

    Scala进阶之路-高级数据类型之集合的使用 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. Scala 的集合有三大类:序列 Seq.集 Set.映射 Map,所有的集合都扩展自 ...

  9. POJ 3252 Round Number(数位DP)

    Round Numbers Time Limit: 2000MS   Memory Limit: 65536K Total Submissions: 6983   Accepted: 2384 Des ...

  10. 流媒体技术学习笔记之(十一)Windows环境运行EasyDarwin

    流媒体平台框架下载安装 Github下载 下载地址:https://github.com/EasyDarwin/EasyDarwin/releases 解压安装 选择Windows 安装平台的安装包( ...