鑑於您的問題的詳細程度,我將重點討論'查詢大型集合',並猜測您正在使用MMAPv1存儲引擎,但沒有索引覆蓋您的查詢。
你是磁盤綁定的嗎?
鑑於上述假設,您可能會在RAM和磁盤之間循環數據。 Mongo有一個默認的100MB內存限制,所以如果你的查詢必須檢查很多文件(沒有索引覆蓋率),從磁盤到RAM的分頁數據可能是罪魁禍首。我聽說過mongo shell會在您超過內存限制時描述或鎖定/終止。
32位系統還可能對大型集合施加嚴重的內存限制。
您可以查看您的操作系統特定的磁盤活動監視器,以瞭解這是否是您的問題。
你的收藏有多大?
接下來,你的收藏有多大?您可以show collections
並查看收集的物理尺寸,也可以db.cards.count()
查看您的記錄數。這有助於量化「大量收集」。
注意:您可能需要mongo-hacker擴展才能查看show collections中的收集磁盤使用情況。
蒙戈外殼調查
在蒙戈外殼,你有一對夫婦更多的地方看看。 默認情況下,mongo會記錄緩慢的查詢(> 100ms)。在您的90秒超時後:
db.adminCommand({getLog: "global" })
並查找慢查詢日誌條目。
接下來看看您的獲獎查詢計劃。
var e = db.cards.explain()
e.find("Field":"Something")
我猜你會看到
"stage": "COLLSCAN",
這意味着你正在做一個完整的集合掃描,你需要索引覆蓋查詢(查詢和排序好主意)。
建議
你應該有任何生產的查詢至少部分索引覆蓋。一個適當的索引應該可以解決你的問題(假設你沒有大於16MB的文檔)。
另一種方法(即我不建議 - 索引是更好)是使用遊標,而不是
var cursor = db.cards.find("Field":"Something")
while (cursor.hasNext()) {
print(tojson(cursor.next()));
}
根據不同的根本原因,這可能會爲你工作。
嘗試使用'db.cards.find()。addOption(DBQuery.Option.noTimeout);'。卡集合中有多少個文檔? – Rudra