MongoDB遊標在執行大量寫入操作時超時

我們有2個副本集的集羣，每集有3個服務器。一個集合被分割。我們還有一些我們每天使用的更多（8+）收藏品。大部分數據都在分片集合中，其中有近1億條記錄。MongoDB遊標在執行大量寫入操作時超時

最近我們增加了獲取我們之前獲得的數據100倍的要求，我們需要將其寫入到mongodb中。一個守護進程已經設置好來執行必要的寫操作，以保持數據庫處於最新狀態。該腳本每秒鐘執行超過200次寫作，大多數都會進入所有單獨的集合。

有了這麼多的寫入量，我們就無法執行大量的讀取操作來進行分析。接收Cursor Timeouts客戶端和服務器端的組合（「未找到光標」）。

我們試圖對讀取進行限制/跳過方案，但問題仍然存在。由於我們既需要大量的寫入，又需要大量的讀取，因此需要採取什麼行動來糾正這種情況？

來源

2011-05-09 Bryan

通常情況下，在這種情況下，您希望開始查看導致時間的查詢。然後你想看看硬件，看看有什麼壓力。

這些查詢是否正確編入索引？
指數有多大？它們適合RAM嗎？
你能提供一些關於瓶頸位置的細節嗎？
你鎖定在IO上嗎？
您的處理器是否全速運行？

另外，在日誌中有什麼不尋常的東西嗎？

基本上，我們需要確保您有： 1.正確構建的系統處理查詢 2.正確配置系統處理的數據量

來源

2011-05-09 19:14:07

1.我們只查詢我們與_id讀領域。 2.我們的索引只比內存大小稍大，我們的EC2實例有7.5 GB，我們的索引每個replSet爲9.5 GB。我們目前正在升級到32 GB的主人。 3.我看不到任何瓶頸，只是問題是完全讀取數據。 4.我們通常是寫鎖定在採取最多寫入的集合，但否則我們很好。 5.我們的處理器根本沒有太大的壓力。 – Bryan 2011-05-09 19:27:14

iostat和mongostat的外觀如何？你在EBS硬盤上運行嗎？搜查？他們的表現如何？ – 2011-05-09 19:44:10

mongostat顯示鎖定的百分比浮動在90％左右，更新占主導地位。我們目前正在對主人和EBS進行二次備份。 iostat在622和365處顯示寫入/秒的讀取/秒，讀取可能很高，因爲我們目前正在恢復2臺32GB服務器。 – Bryan 2011-05-09 19:59:52

MongoDB遊標在執行大量寫入操作時超時

回答

相關問題