一、前情簡(jiǎn)介 ?

半個(gè)月前，公司的MongoDB壓力由于用戶量暴增導(dǎo)致壓力急劇增加，讀寫能力下降。?
因?yàn)閷?duì)于Mongos 的集群分片機(jī)制的了解和測(cè)試還不是很充分，所以開始使用最簡(jiǎn)單的辦法來解決：提高配置。?
眾所周知，MongoDB是出了名的吃 內(nèi)存 。當(dāng)時(shí)定義出來提高M(jìn)ongoDB的辦法很簡(jiǎn)單，插內(nèi)存。?
但是由于機(jī)房問題，插內(nèi)存需要拔電源，導(dǎo)致停止產(chǎn)品的服務(wù)，所以經(jīng)過 研究 后。?
用我們備用的R710 64GB內(nèi)存服務(wù)器來替代線上的R410 32GB內(nèi)存的服務(wù)器。?

二、操作方式 ?

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

三、啟動(dòng)后的驚心動(dòng)魄 ?

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

四、一些性能優(yōu)化 ?

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

五、再一次定位問題 ?

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

六、其實(shí)。。最重要的地方在這里 ?

問題主因就是優(yōu)化不足，還輕率的進(jìn)行了數(shù)據(jù)庫切換。?
MongoDB在R410時(shí)候運(yùn)行，所有的熱點(diǎn)數(shù)據(jù)在內(nèi)存映射Mapping。而R710沒有，需要再規(guī)則下重新進(jìn)行映射。?
最坑爹的就是這里。這段時(shí)間需要很久。而數(shù)據(jù)庫 重啟 導(dǎo)致用戶重連服務(wù)，暴起的連接數(shù)和請(qǐng)求數(shù)直接壓垮數(shù)據(jù)庫。?
甚至?xí)?dǎo)致數(shù)據(jù)庫啟動(dòng)就宕機(jī)的危險(xiǎn)。?

七、動(dòng)作要謹(jǐn)慎。Over ? 與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。