Query
MongoDB對高數據的優化
我有一個mongoDB集合，每天有 42M 寄存器和 1M 新寄存器。
我們發現mongoDB 查詢性能低下。在 mongostat 中顯示欄位：qr|qw ar|aw，值為300-500。
第一步是檢查索引並為可能需要很長時間的查詢創建新索引。
現在我們大部分時間都得到了很好的表現。
但在某些情況下（隨機時間），我們會得到很多處於待處理狀態的連接，查詢速度都很慢。
但是，top 命令在處理速度和記憶體方面顯示出良好的性能。
問題是：
- 我如何進一步檢查未優化的查詢。
- 在 new relic show 這個特定集合中的 INSERT 命令佔用了“最耗時”的 62%，有什麼辦法可以加快速度？
- 為什麼可能是掛起連接的原因？奇怪的是：當數字開始上升時，直到網站崩潰才停止。
編輯：
我們最終通過以下步驟解決了大部分問題：
- 將 mongo 移動到沒有 openvz 的新伺服器，似乎 mongo 給 openvz 帶來了麻煩
- 新的文件系統和 saas。
- 根據我們的需要創建新的索引。
Mongo 現在執行得很好，所以感謝大家的幫助 :)
首先，讓我說，根據給出的資訊，很難找到根本原因——這通常是一個迭代過程，需要多次嘗試才能找到罪魁禍首。為了回答您的“下一步是什麼？” 問題的一部分，而不是確定根本原因，請繼續閱讀…..
首先，有幾點建議：
- 讓主機進入 MMS（它是免費的） - 請參閱http://mms.10gen.com - 這樣您就可以隨時間繪製統計數據並查看問題，而不必坐在盒子上執行命令
- 也安裝 munin-node，這樣您就可以將操作等與 IO 相關聯（安裝 MMS 文件對此進行了解釋）。
接下來，對常見原因進行一些快速檢查：
- 你的文件系統/核心是什麼？- 這些通常需要是 ext4/XFS 並且足夠新才能讓 fallocate 工作（分別為 2.6.23 和 2.6.25），這樣新文件分配不會很慢
- 假設您沒有安裝 MMS 和 munin，讓 iostat 輸出與 mongostat 匹配以確定 IO 是否是瓶頸的根本原因
- 您是否會定期進行批量更新以顯著增加文件（即會導致移動）？移動很昂貴，並且可能導致 IO 得到備份
- 您的磁碟是否達到您正在寫入的數據量？預設情況下，MongoDB 每 60 秒 fsync 一次到磁碟，如果需要在 60 秒後同步的捲很大（比如因為插入峰值），那麼您也可能會遇到問題
這不是一個詳盡的清單，我已經看到其他問題導致了這個，但這應該讓你開始走上正確的道路。