Question

我将MongoDB 3.0.14版（带有wiretiger）用作4个成员副本集。我在生产中遇到一个奇怪的问题，突然大多数查询开始在Global.timeAcquiringMicros.r上阻塞（在Secondary Mongod Server上，那里的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，为什么查询必须获得14次全局意图共享锁（r）？

说明第二个查询的结果（其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

MongoDB辅助节点从主节点中批量检索操作日志事件。当它应用一批oplog事件时，它将采用全局排他写锁（W）。

读取意图锁（r）与W锁互斥。

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

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

如果可以升级，则不再需要进行特定的锁争用。

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

1 个答案: