一、前情簡介 ?

半個月前，公司的MongoDB壓力由于用戶量暴增導致壓力急劇增加，讀寫能力下降。?
因為對于Mongos 的集群分片機制的了解和測試還不是很充分，所以開始使用最簡單的辦法來解決：提高配置。?
眾所周知，MongoDB是出了名的吃 內存 。當時定義出來提高MongoDB的辦法很簡單，插內存。?
但是由于機房問題，插內存需要拔電源，導致停止產品的服務，所以經過 研究 后。?
用我們備用的R710 64GB內存服務器來替代線上的R410 32GB內存的服務器。?

二、操作方式 ?

（1）首先是確認防火墻，端口是否開放，MongoDB1.82升級2.02安裝成功，所有操作在內網進行。?
（2）使用Rsync將R410服務器的MongoDB主庫數據 同步 到R710中。?
同步結束之后，刪除R710本地Local文件。以從庫模式啟動，開始同步R410中MongoDB主庫的數據。?
在同步延時在1s左右。確認數據及時同步。?
（3）在確認數據同步后，切斷所有數據庫Write操作的入口。使MongoDB主庫的數據不再出現變動。?
這之后確認從庫的數據已經與主庫完全同步。進入主庫，shutDownServer()。停止主庫服務。?
然后進入從庫，shutDownServer。停止從庫服務。?
然后再將R710中的從庫以主庫的模式重新啟動。這時同時切換所有訪問數據庫程序的Hosts。使其從R410的主機IP指向到R710的主機IP。這時啟動所有服務。?

三、啟動后的驚心動魄 ?

啟動服務之后，MongoDB并沒有像我們想象中的瘋狂的占用內存，起初只是占用了2.5G左右的內存。?
用戶在頻繁的訪問數據庫，通過MongoStat觀察到。用戶的QR和QW也就是讀寫 隊列 不停堆積。Locked值居高不下。?
明顯是處理不過來。創建的conn連接數越來越多，導致客戶端頻繁的出發TimeOut。?
最后甚至引起了MongoDB鎖死，不再執行任何操作。寫入隊列堆積到20000+。?
之后進行查詢，網上說MongoDB2.02 + R710需要在啟動參數中追加numactl --interleave=all 。
經過添加后，松了一口氣，因為無效。?
之后的幾天頻繁出現問題，MongoDB占用內存最高只打到5GB的熱點數據。?
在昨天中午數據庫徹底鎖死宕機。?
問題被定位在R710的硬件 設備 不兼容上。?
被迫在白天的時候重新操作了一次之前的工作，將數據庫遷移回R410。?
在晚上的時候進行觀測， 發現 數據依然不夠理想。還是一樣的效果。?
之后開始懷疑是因為MongoDB1.82升級到2.02導致的問題，開始查閱資料。但是依然毫無進展。?

四、一些性能優化 ?

之后進行 Nginx 和MongoDB的log觀察。發現每分鐘大概14000的動態請求。而MongoDB的log一直在展示一些可怕的慢查詢，最長的一次竟然有370秒！?
MonogoDB有個很坑爹的地方就Auth驗證，我之前的日志還描述過這個東西，但是沒想到每次創建連接時的密碼驗證竟然成了瓶頸所在。希望大家慎用?？梢赃x擇封閉MongoDB所在主機的外網IP，然后使用內網無密碼訪問最佳。?
之后進行服務器性能優化，在頻繁調用的幾個 接口 緊急使用 緩存 來緩解問題。而一些不重要不需要及時更新的查詢則切換到從庫進行查詢。并切掉了一些需要及時更新的數據接口也訪問從庫，需要mark下數據庫緩解后再調整回去。?
經過追查每一個表的索引發現， 數據表 中有很多冗余索引，有一些沒有作為索引條件查詢，有一些已經被建為聯合索引，卻依然沒有刪除掉。果斷Drop掉這些Index。?
這之后數據的讀寫隊列在300-1000左右，依然是不健康的狀態。?

五、再一次定位問題 ?

這之后MongoDB一直在不健康的狀態但是并沒有再一次宕機。不過 危險 依然存在。?
MongoDB的占用的內存熱點數據依然是5GB左右。崩潰了。?
定位問題到MongoDB的數據由于不在內存中，所以導致讀寫速度障礙。?
寫了一段Java程序進行R710數據庫數據循環插入，希望能測試出是否可以提高內存占用量。?
果然，結果是插入一段時間之后。MongoDB的內存占用已經到達36GB。理想中的結果。?
不過線上環境不能隨便插入數據，所以使用python寫了一段全表掃描數據的 腳本 執行。?
結果竟然無效。?
推論是插入會直接放入熱點中，查詢可能是需要經歷一段時間和幾次的命中才會?？拥?
目前能做的就是等待，等待MongoDB的熱點內存占用提高，才能緩解所有問題。直到Mongos測試OK

六、其實。。最重要的地方在這里 ?

問題主因就是優化不足，還輕率的進行了數據庫切換。?
MongoDB在R410時候運行，所有的熱點數據在內存映射Mapping。而R710沒有，需要再規則下重新進行映射。?
最坑爹的就是這里。這段時間需要很久。而數據庫 重啟 導致用戶重連服務，暴起的連接數和請求數直接壓垮數據庫。?
甚至會導致數據庫啟動就宕機的危險。?

七、動作要謹慎。Over ? 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的MongoDB 性能瓶颈分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。