mongodb查询速度慢，扫描的文档数量少

我有一个3个MongoDB实例的副本集。这些实例具有8GB的RAM和双核2.27GHz CPU。所有实例都运行版本2.2.2（我在2.0.1中看到了相同的行为）

我的问题是：我们的主实例（副本集的主实例）最近养成了每两天爬行到100%CPU的习惯。为了找到原因，我决定运行MongoDB探查器。我发现了数百个非常慢的查询。以下是一个例子：

> db.system.profile.find()
{ 
    "ts" : ISODate("2012-12-16T20:31:39.078Z"), 
    "op" : "command", 
    "ns" : "stylesaint.$cmd", 
    "command" : { 
        "count" : "tears", 
        "query" : { 
            "_id" : { "$gt" : ObjectId("50cdeadeaf58d3de96000294") }, 
            "active" : true, 
            "is_image_processed" : true, 
            "hidden_from_feed" : false, 
            "hidden_from_public_feeds" : false
        }, 
        "fields" : null 
    }, 
    "ntoreturn" : 1, 
    "responseLength" : 48, 
    "millis" : 13930, 
    "client" : "#########"
}

从我所读到的关于mongodb的内容来看，在这些情况下，下一步自然是尝试解释这些查询。但是，explain（）不能解释查询的缓慢程度：

> db.tears.find({ "_id" : { "$gt" : ObjectId("50cdeadeaf58d3de96000294") }, "active" : true, "is_image_processed" : true, "hidden_from_feed" : false, "hidden_from_public_feeds" : false }).explain()
{
    "cursor" : "BtreeCursor id",
    "isMultiKey" : false,
    "n" : 4,
    "nscannedObjects" : 5,
    "nscanned" : 5,
    "nscannedObjectsAllPlans" : 23,
    "nscannedAllPlans" : 25,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : { 
        "_id" : [ 
            [ 
                ObjectId("50cdeadeaf58d3de96000294"), 
                ObjectId("ffffffffffffffffffffffff")
            ]
        ]
    },
    "server" : "#########"
}

扫描5个文档不应花费13秒。正在发生的其他事情正在减慢查询速度。也许其他查询正在耗尽服务器的资源？然而，我不知道去哪里找。非常感谢您提供的任何建议

MongoDB日志

我在启动过程中找不到任何警告：

***** SERVER RESTARTED *****


Sun Dec 16 21:02:56 [initandlisten] MongoDB starting : pid=...
Sun Dec 16 21:02:56 [initandlisten] db version v2.2.2, pdfile version 4.5
Sun Dec 16 21:02:56 [initandlisten] git version: ...   
Sun Dec 16 21:02:56 [initandlisten] build info: Linux 2.6.21.7-2 ...
Sun Dec 16 21:02:56 [initandlisten] options: { config: "/etc/mongodb.conf", dbpath: "/data/mongodb", logappend: "true", logpath: "/var/log/mongodb/mongodb.log", replSet: "...", rest: "true" }
Sun Dec 16 21:02:56 [initandlisten] journal dir=/data/mongodb/journal
Sun Dec 16 21:02:56 [initandlisten] recover : no journal files present, no recovery needed
Sun Dec 16 21:02:56 [initandlisten] waiting for connections on port ...
Sun Dec 16 21:02:56 [websvr] admin web console waiting for connections on port ...
Sun Dec 16 21:02:56 [initandlisten] connection accepted from ...
Sun Dec 16 21:02:56 [conn1] end connection ... (0 connections now open)
Sun Dec 16 21:02:56 [initandlisten] connection accepted from ... #2 (1 connection now open)
Sun Dec 16 21:02:56 [rsStart] replSet I am ...
Sun Dec 16 21:02:56 [rsStart] replSet STARTUP2
Sun Dec 16 21:02:56 [rsHealthPoll] replSet member ... is up
Sun Dec 16 21:02:56 [rsHealthPoll] replSet member ... is now in state SECONDARY
Sun Dec 16 21:02:57 [initandlisten] connection accepted from ... #3 (2 connections now open)
Sun Dec 16 21:02:57 [rsSync] replSet SECONDARY
Sun Dec 16 21:02:58 [initandlisten] connection accepted from ... #4 (3 connections now open)
Sun Dec 16 21:02:58 [initandlisten] connection accepted from ... #5 (4 connections now open)
Sun Dec 16 21:02:58 [conn5] end connection ... (3 connections now open)
Sun Dec 16 21:02:58 [rsHealthPoll] replSet member ... is up
Sun Dec 16 21:02:58 [rsHealthPoll] replSet member ... is now in state PRIMARY
Sun Dec 16 21:02:59 [initandlisten] connection accepted from ... #6 (4 connections now open)
Sun Dec 16 21:03:00 [initandlisten] connection accepted from ... #7 (5 connections now open)
Sun Dec 16 21:03:02 [conn7] end connection ... (4 connections now open)
Sun Dec 16 21:03:03 [rsBackgroundSync] replSet syncing to: ...
Sun Dec 16 21:03:04 [rsSyncNotifier] replset setting oplog notifier to ...
Sun Dec 16 21:03:06 [conn2] end connection ... (3 connections now open)
Sun Dec 16 21:03:06 [initandlisten] connection accepted from ... #8 (4 connections now open)
Sun Dec 16 21:03:08 [initandlisten] connection accepted from ... #9 (5 connections now open)
Sun Dec 16 21:03:13 [initandlisten] connection accepted from ... #10 (6 connections now open)
Sun Dec 16 21:03:13 [conn10] end connection ... (5 connections now open)
Sun Dec 16 21:03:13 [initandlisten] connection accepted from ... #11 (6 connections now open)
Sun Dec 16 21:03:15 [conn3] end connection ... (5 connections now open)
Sun Dec 16 21:03:16 [rsHealthPoll] replSet member .... is now in state SECONDARY
Sun Dec 16 21:03:16 [rsMgr] replSet info electSelf 1
Sun Dec 16 21:03:16 [rsMgr] replSet PRIMARY

Re：请求更多信息

---

目前，MongoDB运行正常；没有超过100毫秒的查询。一旦100%的CPU再次出现，我将发布更多关于系统资源的信息。

首先，我认为这些查询可能是一种误导。您是否在NUMA体系结构下运行这些服务器？你可以通读这本书

如果您在NUMA系统上运行，那么使用numactl以交错策略运行守护程序可能会解决您的问题

您可以检查是否有任何启动警告。它们将在您启动守护进程时出现在您的日志中，并且您可以在守护进程运行时找到它们，尽管我不记得有多激动

---

否则，您可能会在进行这些查询时检查IO操作。如果非要我猜的话，您正在访问磁盘，而不是在内存中使用工作集进行操作。您的内存使用统计数据（mongo控制台中的free-h和内存使用指标）是什么样子的

你的“主要实例”是什么意思？复制版蒙多德的大师？是的，这就是我的意思。我更新了我的问题的更多细节。不知道如何检查我是否使用NUMA系统。。。numactl不在我的道路上，如果这能回答问题的话。我在上次启动时没有看到任何启动警告。只是正常的副本集协商。如果你愿意，我可以发邮件。我将检查我的内存使用情况和IO，并更新上面的帖子。您扫描的数字很好，但mongodb的计数操作在进行计数时必须查看每个可能匹配的文档，这意味着如果它不在您的工作集中，则必须将其从磁盘上加载，这可能会非常缓慢，尤其是当您已经有很多IO争用时。