Python 100%CPU下的Mongod-不确定如何诊断？

我有一个python（python&mongonewbie）应用程序，它每小时通过cron运行一次，以获取数据、清理数据并插入mongo。在执行过程中，应用程序将查询mongo以检查重复项，如果文档是新的，则插入

我最近注意到mongod的cpu利用率为100%。。。我不知道这是什么时候开始发生的

我在一个EC2微实例上运行，该实例具有mongo专用的EBS卷，大小约为2.2GB

我不确定从哪里开始诊断这个问题。以下是系统上stats（）和systemStatus（）的输出：

> db.myApp.stats()
{
"ns" : "myApp.myApp",
"count" : 138096,
"size" : 106576816,
"avgObjSize" : 771.7588923647318,
"storageSize" : 133079040,
"numExtents" : 13,
"nindexes" : 1,
"lastExtentSize" : 27090944,
"paddingFactor" : 1,
"flags" : 1,
"totalIndexSize" : 4496800,
"indexSizes" : {
    "_id_" : 4496800
},
"ok" : 1
}
> db.serverStatus()
{
"host" : "kar",
"version" : "2.0.4",
"process" : "mongod",
"uptime" : 4146089,
"uptimeEstimate" : 3583433,
"localTime" : ISODate("2013-04-07T21:18:05.466Z"),
"globalLock" : {
    "totalTime" : 4146088784941,
    "lockTime" : 1483742858,
    "ratio" : 0.0003578656741237909,
    "currentQueue" : {
        "total" : 0,
        "readers" : 0,
        "writers" : 0
    },
    "activeClients" : {
        "total" : 2,
        "readers" : 2,
        "writers" : 0
    }
},
"mem" : {
    "bits" : 64,
    "resident" : 139,
    "virtual" : 1087,
    "supported" : true,
    "mapped" : 208,
    "mappedWithJournal" : 416
},
"connections" : {
    "current" : 7,
    "available" : 812
},
"extra_info" : {
    "note" : "fields vary by platform",
    "heap_usage_bytes" : 359456,
    "page_faults" : 634
},
"indexCounters" : {
    "btree" : {
        "accesses" : 3431,
        "hits" : 3431,
        "misses" : 0,
        "resets" : 0,
        "missRatio" : 0
    }
},
"backgroundFlushing" : {
    "flushes" : 69092,
    "total_ms" : 448897,
    "average_ms" : 6.497090835407862,
    "last_ms" : 0,
    "last_finished" : ISODate("2013-04-07T21:17:15.620Z")
},
"cursors" : {
    "totalOpen" : 0,
    "clientCursors_size" : 0,
    "timedOut" : 1
},
"network" : {
    "bytesIn" : 297154435,
    "bytesOut" : 222773714,
    "numRequests" : 1721768
},
"opcounters" : {
    "insert" : 138004,
    "query" : 359,
    "update" : 0,
    "delete" : 0,
    "getmore" : 0,
    "command" : 1583416
},
"asserts" : {
    "regular" : 0,
    "warning" : 0,
    "msg" : 0,
    "user" : 0,
    "rollovers" : 0
},
"writeBacksQueued" : false,
"dur" : {
    "commits" : 9,
    "journaledMB" : 0,
    "writeToDataFilesMB" : 0,
    "compression" : 0,
    "commitsInWriteLock" : 0,
    "earlyCommits" : 0,
    "timeMs" : {
        "dt" : 3180,
        "prepLogBuffer" : 0,
        "writeToJournal" : 0,
        "writeToDataFiles" : 0,
        "remapPrivateView" : 0
    }
},
"ok" : 1
}

和最高产量：

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+ COMMAND
18477 mongodb   20   0 1087m 139m 122m R 99.9 23.7  10729:36 mongod 

我很好奇如何调试mongo，以确定这种糟糕的性能发生在哪里/发生了什么/为什么发生

更新：

我学会了使用explain（）获取详细信息，尽管我还不确定如何解释结果

> db.myApp.find({'id':'320969221423124481'}).explain()
{
"cursor" : "BasicCursor",
"nscanned" : 138124,
"nscannedObjects" : 138124,
"n" : 0,
"millis" : 3949,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {

}
}

更新：

好的，我现在看到示例查询（它执行了很多次）花费了将近4秒的时间。我猜它没有使用任何索引。我需要查找如何添加索引…现在就这样做

更新：

所以我做了下面的事情

db.myApp.ensureIndex({'id':1})

---

它修复了一切。嘿。

请参阅我的OP线程，但答案是缺少一个需要添加的索引：

db.myApp.ensureIndex({'id':1})

---

你这样做。为什么不使用atomatic

\u id

？它总是有一个索引。这些id是从web服务返回的。返回的id对于文档总是唯一的，所以我使用它。为这个附加的

id

添加索引。它将只占用您驻留内存的几MB。从

explain（）

中可以看到，正在扫描整个磁盘：

“光标”：“BasicCursor”

和

“nscanned”：138124

，这相当于集合中的文档总数。这将极大地提高您的性能。对，我发现了这一点，并相应地更新了我的答案。您可以将记录id设置为从web服务返回的id，没有真正的理由保留标准id