mongodb查询性能差，分析器估计很高

我的mongodb数据库大约有50Gi大小。大约有4.5万件藏品，大小不等。最大的一家公司拥有约100万份文件

我在AWS的r5.xlarge（32Gi内存，4vCPU）上运行mongodb版本3.6.8，其中500Gi gp2 SSD磁盘作为永久卷安装。它不是分片的，而是使用1个主节点和2个辅助节点进行复制

大多数情况下，查询的性能相当好。然而，查询（插入、更新、获取——这似乎无关紧要）往往需要“很长时间”才能完成。我正试图找出是什么导致了这一切

我为耗时超过10秒的查询启用了评测

这里有一个令人难以置信的例子。它是一个集合的更新，集合中有5个文档，其中资格在_id属性上。跑步需要20秒。分析器显示：

{
    "op" : "update",
    "ns" : "bar.PumpStatus__PumpEventDrivenAppNS",
    "command" : {
        "q" : {
            "_id" : ObjectId("5e43f4b9aae591154193999a")
        },
        "u" : {
            "$inc" : {
                "foo_version" : 1
            },
            "$set" : {
                "PumpId" : "Pump1",
                "Temp" : NumberLong(197),
                "RPMS" : NumberLong(3885),
                "Time" : ISODate("2020-03-04T20:39:11.065Z"),
                "foo_modifiedAt" : ISODate("2020-03-04T20:39:11.946Z"),
                "foo_modifiedBy" : "439b96af-558e-4372-a7b9-d245f48d3d3d"
            }
        },
        "multi" : true,
        "upsert" : false
    },
    "keysExamined" : 1,
    "docsExamined" : 1,
    "nMatched" : 1,
    "nModified" : 1,
    "writeConflicts" : 1,
    "numYield" : 1,
    "locks" : {
        "Global" : {
            "acquireCount" : {
                "r" : NumberLong(3),
                "w" : NumberLong(3)
            }
        },
        "Database" : {
            "acquireCount" : {
                "w" : NumberLong(3)
            }
        },
        "Collection" : {
            "acquireCount" : {
                "w" : NumberLong(2)
            }
        },
        "oplog" : {
            "acquireCount" : {
                "w" : NumberLong(1)
            }
        }
    },
    "millis" : 20001,
    "planSummary" : "IDHACK",
    "execStats" : {
        "stage" : "UPDATE",
        "nReturned" : 0,
        "executionTimeMillisEstimate" : 20008,
        "works" : 3,
        "advanced" : 0,
        "needTime" : 1,
        "needYield" : 1,
        "saveState" : 1,
        "restoreState" : 1,
        "isEOF" : 1,
        "invalidates" : 0,
        "nMatched" : 1,
        "nWouldModify" : 1,
        "nInvalidateSkips" : 0,
        "wouldInsert" : false,
        "fastmodinsert" : false,
        "inputStage" : {
            "stage" : "IDHACK",
            "nReturned" : 1,
            "executionTimeMillisEstimate" : 18351,
            "works" : 1,
            "advanced" : 1,
            "needTime" : 0,
            "needYield" : 0,
            "saveState" : 3,
            "restoreState" : 2,
            "isEOF" : 1,
            "invalidates" : 0,
            "keysExamined" : 1,
            "docsExamined" : 1
        }
    },
    "ts" : ISODate("2020-03-04T20:39:31.948Z"),
    "client" : "10.10.158.164",
    "appName" : "io.myorg.mongodb",
    "allUsers" : [
        {
            "user" : "foo",
            "db" : "bar"
        }
    ],
    "user" : "foo@bar"
}

mongodb估计，使用IDHACK查找文档需要18.351秒，整个执行过程需要20.008秒。瞧，执行时间是20.001秒

我觉得这些数字难以相信。他们可以信任吗？如果是这样，会发生什么事情导致执行时间如此缓慢

集合非常小，没有报告锁等待，如果我手动运行等效的find，它会立即返回。据我所知，该卷的CloudWatch指标并不表示读写操作非常慢。延迟低，IOPS远未接近极限

我知道可以改进的领域：

• 启用

  directoryForIndexes

  将集合和索引拆分到两个卷中
• 在卷上使用XFS
• 确保大型页面被禁用（我认为是）

我怀疑上述任何一项是否能减轻疼痛。我怀疑我在做一些基本上完全错误的事情

---

你对这里可能发生的事情有什么想法吗？

可能是AWS上一个吵闹的邻居偷走了你的cpu时间吗？我不能排除吵闹的邻居。我正在迁移到一个更大的实例（不同的，可能更少的邻居）可能会在您进行mongodb升级时付费。可能是AWS上一个吵闹的邻居偷走了您的cpu时间吗？我不能排除吵闹的邻居。我正在转移到一个更大的实例（不同的，可能更少的邻居）上，在您进行mongodb升级时，可能也需要付费。