1、MongoDB 高并發(fā)集群性能優(yōu)化最佳實(shí)踐背景峰值TPS超過100萬/秒主要為寫流量(insert+update)讀流量幾百上千主從讀寫分離分片模式集群總文檔數(shù)百億條文檔三天后散列任意時間點(diǎn)過期業(yè)務(wù)層面優(yōu)化優(yōu)化前:db.collection.insert( expireAt: new Date(July 22, 2019 01:11:00),xxx: xxxx! )/白天過期db.collection.insert( expireAt: new Date(July 22, 2019 11:11:00),xxx: xxxxx! )/晚上過期過期索引:Db.collection.createInd

2、ex( expireAt: 1 , expireAfterSeconds: 0 )xxx: xxxx! )/之前白天過優(yōu)化后:db.collection.insert( expireAt: new Date(July 22, 2019 01:11:00),期的數(shù)據(jù)，現(xiàn)在業(yè)務(wù)優(yōu)化為晚上過期db.collection.insert( expireAt: new Date(July 22, 2019 02:11:00),xxx: xxxxx! )/晚上過期mongodb配置優(yōu)化(網(wǎng)絡(luò)IO復(fù)用，網(wǎng)絡(luò)IO和磁盤IO做分離)默認(rèn)網(wǎng)絡(luò)線程模型架構(gòu)：默認(rèn)網(wǎng)絡(luò)模型架構(gòu)是每收到一個客戶端鏈接，mongodb會創(chuàng)

3、建一個線程處理該鏈接fd的所有讀寫請求及磁盤IO操作。serviceExecutor: adaptive 線 程 模 型 架 構(gòu) ： adaptive網(wǎng)絡(luò)配置線程模型，不再是一個鏈接創(chuàng)建一個線程，新模式實(shí)現(xiàn)了網(wǎng)絡(luò)IO復(fù)用，同時確保了網(wǎng)絡(luò)IO和磁盤IO做分離。說明: 建議存在高并發(fā)的業(yè)務(wù)場景使用adaptive配置，低流量場景不建議開啟同一集群不同分片同一時刻不同配置性能對比默認(rèn)網(wǎng)絡(luò)線程配置對應(yīng)分片負(fù)載：adaptive網(wǎng)絡(luò)線程配置對應(yīng)分片負(fù)載:默認(rèn)配置對應(yīng)分片慢日志數(shù)(19621)：adaptive配置對應(yīng)慢日志數(shù)(5222)：整體配置替換前后時延對比：wiredtiger存儲引擎優(yōu)化現(xiàn)問題背

4、景：磁盤IO一會兒0%，一會兒持續(xù)性100%，tps有跌0 象存儲引擎調(diào)優(yōu)：cachesize調(diào)整優(yōu)化(120G-50G)cache調(diào)小目的：減少checkpoint刷臟數(shù)據(jù)時的數(shù)據(jù)量，減少磁盤IO跟不上客戶端 寫入速度引起的持續(xù)性IO跌0問題。預(yù)留部分內(nèi)存給內(nèi)核pageCache，盡量避免內(nèi)存不足引起的應(yīng) 用阻塞。存儲引擎調(diào)優(yōu)：dirty臟數(shù)據(jù)淘汰優(yōu)化默認(rèn)存儲引擎配置:wiredtiger淘汰相關(guān)配置默認(rèn)值工作原理eviction_target80當(dāng)用掉的內(nèi)存超過總內(nèi)存的百分比達(dá)到 eviction_target， 后臺evict線程開始淘汰eviction_trigger95當(dāng)用掉的內(nèi)存超

5、過總內(nèi)存的 eviction_trigger，用戶線程 也開始淘汰eviction_dirty_target5當(dāng)cache中臟數(shù)據(jù)比例超過eviction_dirty_target，后臺evict線程開始淘汰eviction_dirty_trigger20當(dāng)cache中臟數(shù)據(jù)比例超過eviction_dirty_trigger, 用戶線程也開始淘汰evict.threads_min4后臺evict線程最小數(shù)evict.threads_max4后臺evict線程最大數(shù)引擎優(yōu)化后的配置:wiredtiger淘汰相關(guān)配置默認(rèn)值優(yōu)化目的eviction_target75總體思想是讓后臺evict盡量早

6、點(diǎn)淘汰臟頁page到磁盤，同 時調(diào)整evict淘汰線程數(shù)來加快兩次checkpoint之間的臟數(shù) 據(jù)淘汰eviction_trigger97eviction_dirty_target3eviction_dirty_trigger25evict.threads_min8evict.threads_max12存儲引擎調(diào)優(yōu)：checkpoint優(yōu)化調(diào)整默認(rèn)配置: checkpoint=(wait=60,log_size=2GB)優(yōu)化后配置：checkpoint=(wait=25,log_size=1GB)總體思想：如果在兩次checkpoint的時間間隔內(nèi)evict淘汰線程淘汰的dirtypage越

7、少，那么積壓的臟數(shù)據(jù)就會越多，也就是checkpoint的時 候臟數(shù)據(jù)就會越多，造成checkpoint的時候IO集中大量寫磁盤。如 果我們把checkpoint的周期縮短，那么兩個checkpoint期間的臟數(shù) 據(jù)相應(yīng)的也就會減少，磁盤IO 100%持續(xù)的時間也就會縮短。存儲引擎優(yōu)化前后IO趨勢對比存儲引擎優(yōu)化前后時延對比服務(wù)器IO系統(tǒng)問題通過和廠商大量測試、固件升級、驅(qū)動調(diào)試等，最終定位到是操作系統(tǒng)版 本問題引起，通過升級該nvme服務(wù)器到3.10.0-957.27.2.el7.x86_64后，問題解 決。升級前后IO狀況對比如下圖所示：服務(wù)器IO問題解決后時延升級服務(wù)器系統(tǒng)版本后，服務(wù)器

8、IO能力有了很大的提升，于是替換集群所有分片的主節(jié)點(diǎn) 為升級后的高IO服務(wù)器(由于升級后的服務(wù)器沒有大規(guī)模使用過，為了謹(jǐn)慎保險起見，從節(jié)點(diǎn)還 是未升級的低IO服務(wù)器)，時延進(jìn)一步降低到平均2-4ms，但是有80ms左右的毛刺，業(yè)務(wù)側(cè)核心的兩個接口時延如下圖所 示：禁用enableMajorityReadConcern禁用原因：mongodb-3.6默認(rèn)啟用了 MajorityReadConcern。啟用該功能后，mongodb必須在內(nèi)存中借助snapshot 及主 從通信來維護(hù)更多的版本信息，以達(dá)到主從一致性的目的。由于從節(jié)點(diǎn)是低IO服務(wù)器，很容易造成阻塞，這樣拉取oplog的速度就會跟不上進(jìn)

9、度，造成主節(jié)點(diǎn)消耗大量的內(nèi)存來維護(hù)快照信息，這樣就會導(dǎo)致大量的內(nèi)存及cpu消耗， 最終導(dǎo)致臟數(shù)據(jù)瞬間劇增，很快達(dá)到eviction_dirty_trigger閥值，業(yè)務(wù)也因此抖動。由于業(yè)務(wù)不需要readConcern(Majority)功能，因此禁掉該配置。說明：如果主從服務(wù)器硬件能力不對等或者PSA模式(主+從+選舉節(jié)點(diǎn))，強(qiáng)烈建議關(guān)閉該配置升級所有分片從節(jié)點(diǎn)到高IO服務(wù)器禁用enableMajorityReadConcern功能及升級所有從節(jié)點(diǎn)到高IO服務(wù)器后，時延從80ms峰值 毛刺減少到了40ms，如下圖所示：存儲引擎繼續(xù)優(yōu)化為了進(jìn)一步減緩時延尖刺，我們繼續(xù)在之前基礎(chǔ)上對存儲引擎調(diào)優(yōu)，

10、調(diào)整后配置如下：eviction_dirty_trigger：30% evict.threads_min: 12 evict.threads_max:18 checkpoint=(wait=20,log_size=1GB)經(jīng)過此輪的存儲引擎調(diào)優(yōu)后，該業(yè)務(wù)的核心接口時延進(jìn)一步好轉(zhuǎn)，時延尖刺相比之前有了進(jìn) 一步的改善，時延最大尖刺時間從前面的40ms降低到了30ms，同時尖刺出現(xiàn)的頻率明顯降低了， 如下圖所示:總結(jié)通過軟件層面(mongodb服務(wù)配置、業(yè)務(wù)優(yōu)化、存儲引擎優(yōu)化)及硬件優(yōu)化(升級操作系統(tǒng))后，該大流量 集群的核心接口時延從最初的平均成百上千ms降低到了現(xiàn)在的平均1-2ms，性能提升比較

11、可觀，整體時延性 能提升數(shù)十倍。優(yōu)化前主要接口時延如下：優(yōu)化后主要接口時延如下：OPPO互聯(lián)網(wǎng)服務(wù)簡介可能外界對OPPO的認(rèn)識僅僅停留在手機(jī)業(yè)務(wù)，這其實(shí)是一種誤解。OPPO的互聯(lián)網(wǎng)業(yè)務(wù)流量絕不輸于部分一線互聯(lián)網(wǎng)公司，當(dāng)前OPPO互聯(lián)網(wǎng)服務(wù)部分主流中間件、數(shù)據(jù)庫等單集群流量峰值已經(jīng)突破了百萬級tps，其中OPPO文檔數(shù)據(jù)庫單集 群最大峰值tps突破150萬/s，總集群峰值tps突破400萬/s，預(yù)計2020年左右文檔數(shù)據(jù)庫總tps突破1000萬/s大關(guān)，歡迎加入OPPO互聯(lián)網(wǎng)云存儲團(tuán)隊(duì)參與挑戰(zhàn)公司百萬級高并發(fā)文檔數(shù)據(jù)庫研發(fā)。OPPO互聯(lián)網(wǎng)文檔數(shù)據(jù)庫團(tuán)隊(duì)后續(xù)分享近期繼續(xù)分享如下主題，敬請關(guān)注：1.百萬級高并發(fā)mongodb集群性能優(yōu)化采坑記2.線上典型集群抖動、不可用等問題匯總分析3.Mongodb文檔數(shù)據(jù)庫業(yè)務(wù)使用最佳案例分享4.Mongodb-3.6網(wǎng)絡(luò)IO線程模型設(shè)計及代碼實(shí)現(xiàn)5. 其他作者簡介楊亞洲，前滴滴出行技術(shù)專家，現(xiàn)任OPPO文檔數(shù)據(jù)庫研發(fā)負(fù)責(zé)人，一直專注于分布式緩存、高性能服務(wù)器、分布式存儲、數(shù)據(jù)庫、中間件等相 關(guān)研發(fā)，后續(xù)