MongoDB 查询在 Global.timeAcquiringMicros.r 上花费大量时间

Question

我正在使用 MongoDB 版本 3.0.14（带有 wiredtiger）作为 4 成员回复集。我在生产中遇到了一个奇怪的问题，突然大多数查询开始在 Global.timeAcquiringMicros.r 上阻塞（在辅助 Mongod 服务器上，java-客户端正在使用 SecondaryPreferred Read Preference 发送正常的读取查询）

2020-06-09T12:30:23.959+0000 I COMMAND  [conn210676] query <db>.<collection> query: { $query: { _id: { $gte: "<value>", $lt: "<value>" } }, $orderby: { _id: -1 }, $maxTimeMS: 16000 } planSummary: IXSCAN { _id: 1 } ntoreturn:0 ntoskip:0 nscanned:11 nscannedObjects:11 keyUpdates:0 writeConflicts:0 numYields:6 nreturned:11 reslen:270641 locks:{ Global: { acquireCount: { r: 14 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 4580895 } }, Database: { acquireCount: { r: 7 } }, Collection: { acquireCount: { r: 7 } } } 1706ms

2020-06-09T12:30:25.887+0000 I COMMAND  [conn210607] query <db>.<collection> query: { $query: { _id: { $gte: "<value1>", $lt: "<value2>" } }, $orderby: { _id: -1 }, $maxTimeMS: 16000 } planSummary: IXSCAN { _id: 1 } cursorid:76676946055 ntoreturn:0 ntoskip:0 nscanned:40 nscannedObjects:40 keyUpdates:0 writeConflicts:0 numYields:12 nreturned:40 reslen:1062302 locks:{ Global: { acquireCount: { r: 26 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 21622755 } }, Database: { acquireCount: { r: 13 } }, Collection: { acquireCount: { r: 13 } } } 3639ms

这些查询正在获取全局数据库上的意向共享锁 (r)，它必须等待 4580895/21622755 微秒（根据 timeAcquiringMicros）。我有以下疑问：

它必须花费 4580895/21622755 微秒，这是怎么回事？我可以保证除了基于 _id 索引
由于Global.timeAcquiringMicros.r很高，我假设有任何操作对全局数据库进行'R'，'W'锁定，那么，捕获此类查询的方法是什么？我已经尝试 db.currentOp() 但找不到任何东西。
Global.acquireCount=14，为什么查询要取全局意向共享锁（r）14次？

解释第二个查询的结果（Global.timeAcquiringMicros.r = 21622755）：

{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "<db>.<coll>",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "$and" : [
                {
                    "_id" : {
                        "$lt" : "<stop>"
                    }
                },
                {
                    "_id" : {
                        "$gte" : "<start>"
                    }
                }
            ]
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "_id" : 1
                },
                "indexName" : "_id_",
                "isMultiKey" : false,
                "direction" : "backward",
                "indexBounds" : {
                    "_id" : [
                        "(\"<stop>\", \"<start>\"]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ ]
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 69,
        "executionTimeMillis" : 57,
        "totalKeysExamined" : 69,
        "totalDocsExamined" : 69,
        "executionStages" : {
            "stage" : "FETCH",
            "nReturned" : 69,
            "executionTimeMillisEstimate" : 50,
            "works" : 70,
            "advanced" : 69,
            "needTime" : 0,
            "needFetch" : 0,
            "saveState" : 2,
            "restoreState" : 2,
            "isEOF" : 1,
            "invalidates" : 0,
            "docsExamined" : 69,
            "alreadyHasObj" : 0,
            "inputStage" : {
                "stage" : "IXSCAN",
                "nReturned" : 69,
                "executionTimeMillisEstimate" : 0,
                "works" : 70,
                "advanced" : 69,
                "needTime" : 0,
                "needFetch" : 0,
                "saveState" : 2,
                "restoreState" : 2,
                "isEOF" : 1,
                "invalidates" : 0,
                "keyPattern" : {
                    "_id" : 1
                },
                "indexName" : "_id_",
                "isMultiKey" : false,
                "direction" : "backward",
                "indexBounds" : {
                    "_id" : [
                        "(\"<stop>\", \"<start>\"]"
                    ]
                },
                "keysExamined" : 69,
                "dupsTested" : 0,
                "dupsDropped" : 0,
                "seenInvalidated" : 0,
                "matchTested" : 0
            }
        }
    },
    "serverInfo" : {
        "host" : "<host>",
        "port" : 27017,
        "version" : "3.0.14",
        "gitVersion" : "08352afcca24bfc145240a0fac9d28b978ab77f3"
    },
    "ok" : 1
}

当这种行为发生时，我能够捕获 currentOp() 之一：

{
            "desc" : "conn225729",
            "threadId" : "0x1321c1400",
            "connectionId" : 225729,
            "opid" : 189970948,
            "active" : false,
            "op" : "getmore",
            "ns" : "<db>.<coll>",
            "query" : {

            },
            "client" : "<client-ip>:55596",
            "numYields" : 0,
            "locks" : {
                "Global" : "r"
            },
            "waitingForLock" : true,
            "lockStats" : {
                "Global" : {
                    "acquireCount" : {
                        "r" : NumberLong(1)
                    },
                    "acquireWaitCount" : {
                        "r" : NumberLong(1)
                    },
                    "timeAcquiringMicros" : {
                        "r" : NumberLong(7500907)
                    }
                }
            }
}

这里的问题也是一样的，正常查询等待 Global.timeAcquiringMicros.r ("waitingForLock" : true)

请帮助并参考一些 MongoDB 解释问题的文档。另外，如果需要任何其他日志，请告诉我。

Answer 1

A MongoDB 辅助节点从主节点批量检索操作日志事件。当它应用一批 oplog 事件时，它需要一个全局独占写锁 (W)。

读意图锁(r) 与W 锁互斥。

这意味着写入和读取必须在辅助节点上交错，因此大量写入会阻塞读取，大量读取会延迟复制。

Non-blocking secondary reads 是几年前 MongoDB 4.0 的主要功能。

如果您可以升级，则不会再发生特定的锁争用。

MongoDB 查询在 Global.timeAcquiringMicros.r 上花费大量时间

MongoDB queries spending lots of time on Global.timeAcquiringMicros.r

mongodb

mongodb-query

wiredtiger