监控Mongo慢查询

1. 使用mongostat监控MongoDB全局情况

 mongostat是mongdb自带的状态检测工具，在命令行下使用。它会间隔固定时间获取MongoDB的当前运行状态，并输出。

 如果你发现数据库突然变慢或者有其他问题的话，你第一手的操作就考虑采用mongostat来查看mongo的状态。

 mongostat --host localhost:27017 -uroot -p123456 --authenticationDatabase admin

 参数说明：

 host:指定IP地址和端口，也可以只写IP，然后使用--port参数指定端口号

 -u： 如果开启了认证，则需要在其后填写用户名

 -p:  密码

 --authenticationDatabase：若开启了认证，则需要在此参数后填写认证库（注意是认证上述账号的数据库）

mongostat输出详解

insert/s : 官方解释是每秒插入数据库的对象数量，如果是slave，则数值前有*,则表示复制集操作

query/s : 每秒的查询操作次数

update/s : 每秒的更新操作次数

delete/s : 每秒的删除操作次数

getmore/s: 每秒查询cursor(游标)时的getmore操作数

command: 每秒执行的命令数，在主从系统中会显示两个值(例如 3|0),分表代表 本地|复制 命令

注： 一秒内执行的命令数比如批量插入，只认为是一条命令（所以意义应该不大）

dirty: 仅仅针对WiredTiger引擎，官网解释是脏数据字节的缓存百分比

used:仅仅针对WiredTiger引擎，官网解释是正在使用中的缓存百分比

flushes:

For WiredTiger引擎：指checkpoint的触发次数在一个轮询间隔期间

For MMAPv1 引擎：每秒执行fsync将数据写入硬盘的次数

注：一般都是0，间断性会是1， 通过计算两个1之间的间隔时间，可以大致了解多长时间flush一次。flush开销是很大的，

    如果频繁的flush,可能就要找找原因了

vsize： 虚拟内存使用量，单位MB （这是 在mongostat 最后一次调用的总数据）

res:  物理内存使用量，单位MB （这是 在mongostat 最后一次调用的总数据）

注：这个和你用top看到的一样, vsize一般不会有大的变动， res会慢慢的上升，如果res经常突然下降，去查查是否有别的程序狂吃内存。

qr: 客户端等待从MongoDB实例读数据的队列长度

qw: 客户端等待从MongoDB实例写入数据的队列长度

ar: 执行读操作的活跃客户端数量

aw: 执行写操作的活客户端数量

注：如果这两个数值很大，那么就是DB被堵住了，DB的处理速度不及请求速度。看看是否有开销很大的慢查询。如果查询一切正常，确实是负载很大，就需要加机器了

netIn:MongoDB实例的网络进流量

netOut：MongoDB实例的网络出流量

注：此两项字段表名网络带宽压力，一般情况下，不会成为瓶颈

conn: 打开连接的总数，是qr,qw,ar,aw的总和

注：MongoDB为每一个连接创建一个线程，线程的创建与释放也会有开销，所以尽量要适当配置连接数的启动参数，

   maxIncomingConnections，阿里工程师建议在5000以下，基本满足多数场景

set: 副本集的名称

repl: 节点的复制状态

 M     ---master

 SEC     ---secondary

 REC     ---recovering

 UNK     ---unknown

 SLV     ---slave

 RTR     ---mongs process("router')

 ARB     ---arbiter

2. 使用Profiling捕捉慢查询

类似于MySQL的slow log, mongodb可以监控所有慢的以及不慢的查询。这个工具就是Profiling，该工具在运行的实例上收集有关MongoDB的写操作，游标，数据库命令等，可以在数据库级别开启该工具，也可以在实例级别开启。该工具会把收集到的所有都写入到system.profile集合中，该集合是一个capped collection。Profiling功能肯定是会影响效率的，但是不太严重，原因是他使用的是system.profile 来记录，而system.profile 是一个capped collection，这种collection 在操作上有一些限制和特点，但是效率更高。

2.1 慢查询分析过程

1. 设置一个时间阀值,比如200ms

2. 在profiling中(system.profile)找到超过200ms的语句

3. 查看execStats,分析执行计划

4. 根据分析结果,决定是不是需要添加索引

2.2 Profiling基本操作

mongoshell(或者其他客户端比如mongochef等）

#查看状态：级别和时间

PRIMARY> db.getProfilingStatus()

{ "was" : 1, "slowms" : 200 }

#查看级别

PRIMARY> db.getProfilingLevel()

#级别说明:

0：关闭，不收集任何数据。

1：收集慢查询数据，默认是100毫秒。

2：收集所有数据

#设置级别

PRIMARY> db.setProfilingLevel(2)

{ "was" : 1, "slowms" : 100, "ok" : 1 }  #这里返回的是上一次的设置

#设置级别和时间

PRIMARY> db.setProfilingLevel(1,200)

{ "was" : 2, "slowms" : 100, "ok" : 1 }  #这里返回的是上一次的设置

#关闭Profiling

PRIMARY> db.setProfilingLevel(0)

{ "was" : 1, "slowms" : 200, "ok" : 1 }  #这里返回的是上一次的设置

#清空system.profile或者修改大小

#关闭Profiling

PRIMARY> db.setProfilingLevel(0)

{ "was" : 0, "slowms" : 200, "ok" : 1 }

#删除system.profile集合

PRIMARY> db.system.profile.drop()

true

#创建一个新的system.profile集合 --- 4M

PRIMARY> db.createCollection( "system.profile", { capped: true, size:4000000 } )

{ "ok" : 1 }

#重新开启Profiling

PRIMARY> db.setProfilingLevel(1,200)

{ "was" : 0, "slowms" : 200, "ok" : 1 }

#如果是复制集环境,要修改副本的system.profile的大小,必须把副本先从复制集中剔除,然后执行上述步骤,最后加入复制集。

#也可以MongoDB启动时,开启Profiling

mongod --profile=1  --slowms=200

#或者在配置文件里添加

profile = 1

slowms = 200

3. 日常使用的Profiling查询脚本

#返回最近的10条记录

db.system.profile.find().limit(10).sort({ts:-1}).pretty()

#返回所有的操作，除command类型的

db.system.profile.find({op: {$ne:'command'}}).pretty()

#返回特定集合

db.system.profile.find({ns:'mydb.test'}).pretty()

#返回大于5毫秒慢的操作

db.system.profile.find({millis:{$gt:5}}).pretty()

#从一个特定的时间范围内返回信息

db.system.profile.find(

                  {

                   ts : {

                         $gt : new ISODate("2015-10-18T03:00:00Z"),

                         $lt : new ISODate("2015-10-19T03:40:00Z")

                        }

                  }

                 ).pretty()

#特定时间，限制用户，按照消耗时间排序

db.system.profile.find(

                  {

                    ts : {

                          $gt : newISODate("2015-10-12T03:00:00Z") ,

                          $lt : newISODate("2015-10-12T03:40:00Z")

                         }

                  },

                  { user : 0 }

                 ).sort( { millis : -1 } )

#查看最新的 Profile  记录：

db.system.profile.find().sort({$natural:-1}).limit(1)

# 显示5个最近的事件

show profile

4. 案例分析

4.1 获取慢查询

#下面的语句过滤几个大表,因为基本无法优化,需要开发改逻辑,所以做了排除，在输出方面只输出了个人认为重要的,方便分析迅速定位

db.system.profile.find({"ns":{"$not":{"$in":["F10data3.f10_4_4_1_gsgg_content", "F10data3.f10_5_1_1_gsyb_content"]}}}, {"ns":1,"op":1, "query":1,"keysExamined":1,"docsExamined":1,"numYield":1, "planSummary":1,"responseLength":1,"millis":1,"execStats":1}).limit(10).sort({ts:-1}).pretty()

#下面是一个超过200ms的查询语句

{

"op" : "query",                     #操作类型，有insert、query、update、remove、getmore、command

"ns" : "F10data3.f10_2_8_3_jgcc",

"query" : {                         #具体的查询语句 包括过滤条件，limit行数  排序字段

    filter" : {

        "jzrq" : {

            "$gte" : ISODate("2017-03-31T16:00:00.000+0000"),

            "$lte" : ISODate("2017-06-30T15:59:59.000+0000")

        },

        "jglxfldm" : 10.0

    },

    "ntoreturn" : 200.0,

    "sort" : {                      #如果有排序  则显示排序的字段 这里是 RsId

        "RsId" : 1.0

    }

},

"keysExamined" : 0.0,               #索引扫描数量 这里是全表扫描，没有用索引 所以是 0

"docsExamined" : 69608.0,           #浏览的文档数 这里是全表扫描 所以是整个collection中的全部文档数

"numYield" : 546.0,                 #该操作为了使其他操作完成而放弃的次数。通常来说，当他们需要访问

                                    还没有完全读入内存中的数据时，操作将放弃。这使得在MongoDB为了

                                    放弃操作进行数据读取的同时，还有数据在内存中的其他操作可以完成。

"locks" : {                         #锁信息，R：全局读锁；W：全局写锁；r：特定数据库的读锁；w：特定数据库的写锁

    "Global" : {

        "acquireCount" : {

            "r" : NumberLong(1094)  #该操作获取一个全局级锁花费的时间。

        }

    },

    "Database" : {

        "acquireCount" : {

            "r" : NumberLong(547)

        }

    },

    "Collection" : {

        "acquireCount" : {

            "r" : NumberLong(547)

        }

    }

},

"nreturned" : 200.0,                #返回的文档数量

"responseLength" : 57695.0,         #返回字节长度，如果这个数字很大，考虑值返回所需字段

"millis" : 264.0,                   #消耗的时间（毫秒）

"planSummary" : "COLLSCAN, COLLSCAN", #执行概览 从这里看来 是全表扫描

"execStats" : {                       #详细的执行计划 这里先略过 后续可以用 explain来具体分析

},

"ts" : ISODate("2017-08-24T02:32:49.768+0000"),  #命令执行的时间

"client" : "10.3.131.96",                        #访问的ip或者主机

"allUsers" : [

],

"user" : ""

}

4.2 分析慢查询

 1. 如果发现 millis 值比较大，那么就需要作优化。

 2. 如果docsExamined数很大，或者接近记录总数（文档数），那么可能没有用到索引查询，而是全表扫描。

 3. 如果keysExamined数为0，也可能是没用索引。

 4. 结合 planSummary 中的显示，上例中是  "COLLSCAN, COLLSCAN" 确认是全表扫描

 5. 如果 keysExamined 值高于 nreturned 的值，说明数据库为了找到目标文档扫描了很多文档。这时可以考虑创建索引来提高效率。

 6. 索引的键值选择可以根据 query 中的输出参考，上例中 filter:包含了 jzrq和jglxfldm 并且按照RsId排序，所以 我们的索引

    索引可以这么建: db.f10_2_8_3_jgcc.ensureindex({jzrq:1,jglxfldm:1,RsId:1})

4.3 执行计划中的TYPE类型

COLLSCAN     #全表扫描                                                避免

IXSCAN       #索引扫描                                                可以改进 选用更高效的索引

FETCH        #根据索引去检索指定document

SHARD_MERGE  #将各个分片返回数据进行merge                               尽可能避免跨分片查询

SORT         #表明在内存中进行了排序（与老版本的scanAndOrder:true一致）   排序要有index

LIMIT        #使用limit限制返回数                                      要有限制 Limit+（Fetch+ixscan）最优

SKIP         #使用skip进行跳过                                         避免不合理的skip

IDHACK       #针对_id进行查询                                          推荐,_id 默认主键,查询速度快

SHARDING_FILTER  #通过mongos对分片数据进行查询                          SHARDING_FILTER+ixscan最优

COUNT        #利用db.coll.explain().count()之类进行count运算

COUNTSCAN    #count不使用Index进行count时的stage返回                    避免 这种情况建议加索引

COUNT_SCAN   #count使用了Index进行count时的stage返回                    推荐

SUBPLA       #未使用到索引的$or查询的stage返回                           避免

TEXT         #使用全文索引进行查询时候的stage返回

PROJECTION   #限定返回字段时候stage的返回                                选择需要的数据, 推荐PROJECTION+ixscan

巴特西

监控Mongo慢查询