MongoDB高并發(fā)集群性能優(yōu)化最佳實(shí)踐

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

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

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

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

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

6、點(diǎn)淘汰臟頁(yè)page到磁盤(pán)，同 時(shí)調(diào)整evict淘汰線程數(shù)來(lái)加快兩次checkpoint之間的臟數(shù) 據(jù)淘汰eviction_trigger97eviction_dirty_target3eviction_dirty_trigger25evict.threads_min8evict.threads_max12存儲(chǔ)引擎調(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的時(shí)間間隔內(nèi)evict淘汰線程淘汰的dirtypage越

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

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

9、度，造成主節(jié)點(diǎn)消耗大量的內(nèi)存來(lái)維護(hù)快照信息，這樣就會(huì)導(dǎo)致大量的內(nèi)存及cpu消耗， 最終導(dǎo)致臟數(shù)據(jù)瞬間劇增，很快達(dá)到eviction_dirty_trigger閥值，業(yè)務(wù)也因此抖動(dòng)。由于業(yè)務(wù)不需要readConcern(Majority)功能，因此禁掉該配置。說(shuō)明：如果主從服務(wù)器硬件能力不對(duì)等或者PSA模式(主+從+選舉節(jié)點(diǎn))，強(qiáng)烈建議關(guān)閉該配置升級(jí)所有分片從節(jié)點(diǎn)到高IO服務(wù)器禁用enableMajorityReadConcern功能及升級(jí)所有從節(jié)點(diǎn)到高IO服務(wù)器后，時(shí)延從80ms峰值 毛刺減少到了40ms，如下圖所示：存儲(chǔ)引擎繼續(xù)優(yōu)化為了進(jìn)一步減緩時(shí)延尖刺，我們繼續(xù)在之前基礎(chǔ)上對(duì)存儲(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)過(guò)此輪的存儲(chǔ)引擎調(diào)優(yōu)后，該業(yè)務(wù)的核心接口時(shí)延進(jìn)一步好轉(zhuǎn)，時(shí)延尖刺相比之前有了進(jìn) 一步的改善，時(shí)延最大尖刺時(shí)間從前面的40ms降低到了30ms，同時(shí)尖刺出現(xiàn)的頻率明顯降低了， 如下圖所示:總結(jié)通過(guò)軟件層面(mongodb服務(wù)配置、業(yè)務(wù)優(yōu)化、存儲(chǔ)引擎優(yōu)化)及硬件優(yōu)化(升級(jí)操作系統(tǒng))后，該大流量 集群的核心接口時(shí)延從最初的平均成百上千ms降低到了現(xiàn)在的平均1-2ms，性能提升比較

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