MongoDB慢查询日志

        熟悉 Mysql 的人应该知道,Mysql 是有个慢查询日志的,它可以帮助我们进行优化我们的 sql,并提高我们系统的稳定性和流畅性。那么 MongoDB 中是否也有类似的功能吗? 是有的,它就是 Database Profiler(下面我直接称为慢查询了),我们可以通过设置 Database Profiler 来记录一些超过阈值的查询。然后我们后期可以通过这些记录进行优化查询。

        MongoDB 的 慢查询记录储存在 system.profile 里,默认情况下是关闭的,我们可以在数据库级别上或者是节点级别上配置。

        状态码及相关描述:

        0:表示关闭慢查询,默认情况下

        1:表示超过阈值的查询收集

        2:为所有数据库开启慢查询记录,收集所有的数据

1、启动方式

        MongoDB慢查询有两种启动方式:

        1)通过 MongoDB shell 启用

        #  为所有数据库开启慢查询记录

        db.setProfilingLevel(2)

        #  指定数据库,并指定阈值慢查询 ,超过20毫秒的查询被记录

        use testdb.setProfilingLevel(1, { slowms: 20 })

        #  随机采集慢查询的百分比值,sampleRate 值默认为1,表示都采集,0.42 表示采集42%的内容。

        db.setProfilingLevel(1, { sampleRate: 0.42 })

        # 查询慢查询级别和其它信息

        db.getProfilingStatus()

        # 仅返回慢查询级别

        db.getProfilingLevel()

        # 禁用慢查询

        db.setProfilingLevel(0)

        2)通过配置文件启用

        在ini 配置文件 mongodb.conf 添加以下参数, profile参数是设置开启等级,slowms是设置阈值

        profile = 1

        slowms = 300

        在 YAML配置 文件配置

        operationProfiling:  

            mode:<string># 默认为 off,可选值 off、slowOp(对应上面的等级 1)、all(对应上面的等级 2)   

            slowOpThresholdMs:<int># 阈值,默认值为100,单位毫秒  

            slowOpSampleRate:<double>#  随机采集慢查询的百分比值,sampleRate 值默认为1,表示都采集,0.42 表示采集42%的内容

2、慢查询常用命令

        # 查询最近的10个慢查询日志

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

        # 查询除命令类型为 ‘command’ 的日志

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

        # 查询数据库为 mydb 集合为 test 的 日志

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

        # 查询 低于 5毫秒的日志

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

        # 查询时间从 2012-12-09 3点整到 2012-12-09 3点40分之间的日志

        db.system.profile.find({

            ts : {

                $gt: new ISODate("2012-12-09T03:00:00Z"),

                $lt: new ISODate("2012-12-09T03:40:00Z")

            }

        }).pretty()

3、MongoDB慢查询日志解析

{

  "op" : "query",  # 操作类型,值可为command、count、distinct、geoNear、getMore、group、insert、mapReduce、query、remove、update

  "ns" : "test.report", # 操作的数据库和集合

  "command" : {    # 命令

      "find" : "report",  # 操作的集合

      "filter" : { "a" : { "$lte" : 500 } }, # 查询条件

      "lsid" : {   

        "id" : UUID("5ccd5b81-b023-41f3-8959-bf99ed696ce9") #用户的会话id

      },

      "$db" : "test"  # 操作的数据库

  },

  "cursorid" : 33629063128,  # query和getmore 的游标id

  "keysExamined" : 101, # MongoDB为执行操作而扫描的索引键的数量

  "docsExamined" : 101, # MongoDB为了执行操作而扫描的集合中的文档数。

  "numYield" : 2, # 让步次数,操作时让其他的操作完成的次数。

  "nreturned" : 101, # 操作返回的文档数

  "queryHash" : "811451DD", # 查询的hash值

  "planCacheKey" : "759981BA",

  "locks" : {  # 操作期间的锁和所的类型

      "Global" : {  #表示全局锁定

        "acquireCount" : { #锁定的次数

            "r" : NumberLong(3)  # 表示共享锁

        }

      },

      "Database" : {  # 数据库锁

        "acquireCount" : { "r" : NumberLong(1) },

        "acquireWaitCount" : { "r" : NumberLong(1) },

        "timeAcquiringMicros" : { "r" : NumberLong(69130694) }

      },

      "Collection" : {  # 集合锁

        "acquireCount" : { "r" : NumberLong(1) }

      }

  },

  "storage" : { # 储存

      "data" : {

        "bytesRead" : NumberLong(14736), #操作 从磁盘放到缓存的数据的字节数

        "timeReadingMicros" : NumberLong(17) # 操作 花费在磁盘读取的时间,以微妙为单位

      }

  },

  "responseLength" : 1305014, # 操作返回结果的文档长度,单位为字节

  "protocol" : "op_msg", # 消息的协议

  "millis" : 69132, # 从 MongoDB 操作开始到结束耗费的时间

  "planSummary" : "IXSCAN { a: 1, _id: -1 }",  # 摘要

  "execStats" : {  # 操作执行过程中的详细信息

      "stage" : "FETCH", # 操作形式 ,COLLSCAN 用于集合扫描,IXSCAN 用于扫描索引键,FETCH 用于检索文档

      "nReturned" : 101, # 返回的文档数量

      "executionTimeMillisEstimate" : 0,

      "works" : 101,

      "advanced" : 101,

      "needTime" : 0,

      "needYield" : 0,

      "saveState" : 3,

      "restoreState" : 2,

      "isEOF" : 0,

      "invalidates" : 0,

      "docsExamined" : 101,

      "alreadyHasObj" : 0,

      "inputStage" : {

        ...

      }

  },

  "ts" : ISODate("2019-01-14T16:57:33.450Z"), #操作的时间戳

  "client" : "127.0.0.1",  # 客户端的ip

  "appName" : "MongoDB Shell", #客户端应用标识符

  "allUsers" : [

      {

        "user" : "someuser", # 用户

        "db" : "admin"  # 验证的数据库

      }

  ],

  "user" : "someuser@admin"  # 经过验证的用户

}

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,172评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,346评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,788评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,299评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,409评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,467评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,476评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,262评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,699评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,994评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,167评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,827评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,499评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,149评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,387评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,028评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,055评论 2 352