Oppo文檔數(shù)據(jù)庫研發(fā)負(fù)責(zé)人:楊亞洲
1.背景
線上某集群峰值TPS超過100萬/秒左右(主要為寫流量，讀流量較少，讀寫流量做了主從讀寫分離，讀流量走從節(jié)點(diǎn)，qps數(shù)百上千)，峰值tps幾乎已經(jīng)到達(dá)集群上限，同時(shí)平均時(shí)延也超過100ms，隨著讀寫流量的進(jìn)一步增加，時(shí)延抖動(dòng)嚴(yán)重影響業(yè)務(wù)可用性。該集群采用mongodb天然的分片模式架構(gòu)，數(shù)據(jù)均衡的分布于各個(gè)分片中，添加片鍵啟用分片功能后實(shí)現(xiàn)完美的負(fù)載均衡。集群每個(gè)節(jié)點(diǎn)流量監(jiān)控如下圖所示:
從上圖可以看出集群流量比較大，峰值已經(jīng)突破120萬/秒，其中delete過期刪除的流量不算在總流量里面(delete由主觸發(fā)刪除，但是主上面不會(huì)顯示，只會(huì)在從節(jié)點(diǎn)拉取oplog的時(shí)候顯示)。如果算上主節(jié)點(diǎn)的delete流量，峰值總tps超過150萬/秒。
2.軟件優(yōu)化
在不增加服務(wù)器資源的情況下，首先做了如下軟件層面的優(yōu)化，并取得了理想的數(shù)倍性能提升：
業(yè)務(wù)層面優(yōu)化
Mongodb配置優(yōu)化
存儲(chǔ)引擎優(yōu)化
2.1 業(yè)務(wù)層面優(yōu)化
該集群總文檔近百億條，每條文檔記錄默認(rèn)保存三天，業(yè)務(wù)隨機(jī)散列數(shù)據(jù)到三天后任意時(shí)間點(diǎn)隨機(jī)過期淘汰。由于文檔數(shù)目很多，白天平峰監(jiān)控可以發(fā)現(xiàn)從節(jié)點(diǎn)經(jīng)常有大量delete操作，甚至部分時(shí)間點(diǎn)delete刪除操作數(shù)已經(jīng)超過了業(yè)務(wù)方讀寫流量，因此考慮把delete過期操作放入夜間進(jìn)行，過期索引添加方法如下:
Db.collection.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )
上面的過期索引中expireAfterSeconds=0，代表collection集合中的文檔的過期時(shí)間點(diǎn)在expireAt時(shí)間點(diǎn)過期，例如： db.collection.insert( {
//表示該文檔在夜間凌晨1點(diǎn)這個(gè)時(shí)間點(diǎn)將會(huì)被過期刪除
"expireAt": new Date('July 22, 2019 01:00:00'),
"logEvent": 2,
"logMessage": "Success!"
} )
通過隨機(jī)散列expireAt在三天后的凌晨任意時(shí)間點(diǎn)，即可規(guī)避白天高峰期觸發(fā)過期索引引入的集群大量delete，從而降低了高峰期集群負(fù)載，最終減少業(yè)務(wù)平均時(shí)延及抖動(dòng)。
Delete過期Tips1: expireAfterSeconds含義
1. 在expireAt指定的絕對(duì)時(shí)間點(diǎn)過期，也就是12.22日凌晨2:01過期
Db.collection.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )
db.log_events.insert( { "expireAt": new Date(Dec 22, 2019 02:01:00'),"logEvent": 2,"logMessage": "Success!"})
在expireAt指定的時(shí)間往后推遲expireAfterSeconds秒過期，也就是當(dāng)前時(shí)間往后推遲60秒過期
db.log_events.insert( {"createdAt": new Date(),"logEvent": 2,"logMessage": "Success!"} )
Db.collection.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 60 } )
Delete過期Tips2: 為何mongostat只能監(jiān)控到從節(jié)點(diǎn)有delete操作，主節(jié)點(diǎn)沒有？
原因是過期索引只在master主節(jié)點(diǎn)觸發(fā)，觸發(fā)后主節(jié)點(diǎn)會(huì)直接刪除調(diào)用對(duì)應(yīng)wiredtiger存儲(chǔ)引擎接口做刪除操作，不會(huì)走正常的客戶端鏈接處理流程，因此主節(jié)點(diǎn)上看不到delete統(tǒng)計(jì)。
主節(jié)點(diǎn)過期delete后會(huì)生存對(duì)于的delete oplog信息，從節(jié)點(diǎn)通過拉取主節(jié)點(diǎn)oplog然后模擬對(duì)于client回放，這樣就保證了主數(shù)據(jù)刪除的同時(shí)從數(shù)據(jù)也得以刪除，保證數(shù)據(jù)最終一致性。從節(jié)點(diǎn)模擬client回放過程將會(huì)走正常的client鏈接過程，因此會(huì)記錄delete count統(tǒng)計(jì)，詳見如下代碼:
官方參考如下: https://docs.mongodb.com/manual/tutorial/expire-data/
2.2 Mongodb配置優(yōu)化(網(wǎng)絡(luò)IO復(fù)用，網(wǎng)絡(luò)IO和磁盤IO做分離)
由于集群tps高，同時(shí)整點(diǎn)有大量推送，因此整點(diǎn)并發(fā)會(huì)更高，mongodb默認(rèn)的一個(gè)請(qǐng)求一個(gè)線程這種模式將會(huì)嚴(yán)重影響系統(tǒng)負(fù)載，該默認(rèn)配置不適合高并發(fā)的讀寫應(yīng)用場景。官方介紹如下:
2.2.1 Mongodb內(nèi)部網(wǎng)絡(luò)線程模型實(shí)現(xiàn)原理
mongodb默認(rèn)網(wǎng)絡(luò)模型架構(gòu)是一個(gè)客戶端鏈接，mongodb會(huì)創(chuàng)建一個(gè)線程處理該鏈接fd的所有讀寫請(qǐng)求及磁盤IO操作。
Mongodb默認(rèn)網(wǎng)絡(luò)線程模型不適合高并發(fā)讀寫原因如下:
1. 在高并發(fā)的情況下，瞬間就會(huì)創(chuàng)建大量的線程，例如線上的這個(gè)集群，連接數(shù)會(huì)瞬間增加到1萬左右，也就是操作系統(tǒng)需要瞬間創(chuàng)建1萬個(gè)線程，這樣系統(tǒng)load負(fù)載就會(huì)很高。
2. 此外，當(dāng)鏈接請(qǐng)求處理完，進(jìn)入流量低峰期的時(shí)候，客戶端連接池回收鏈接，這時(shí)候mongodb服務(wù)端就需要銷毀線程，這樣進(jìn)一步加劇了系統(tǒng)負(fù)載，同時(shí)進(jìn)一步增加了數(shù)據(jù)庫的抖動(dòng)，特別是在PHP這種短鏈接業(yè)務(wù)中更加明顯，頻繁的創(chuàng)建線程銷毀線程造成系統(tǒng)高負(fù)債。
3. 一個(gè)鏈接一個(gè)線程，該線程除了負(fù)責(zé)網(wǎng)絡(luò)收發(fā)外，還負(fù)責(zé)寫數(shù)據(jù)到存儲(chǔ)引擎，整個(gè)網(wǎng)絡(luò)I/O處理和磁盤I/O處理都由同一個(gè)線程負(fù)責(zé)，本身架構(gòu)設(shè)計(jì)就是一個(gè)缺陷。
2.2.2 網(wǎng)絡(luò)線程模型優(yōu)化方法
為了適應(yīng)高并發(fā)的讀寫場景，mongodb-3.6開始引入serviceExecutor: adaptive配置，該配置根據(jù)請(qǐng)求數(shù)動(dòng)態(tài)調(diào)整網(wǎng)絡(luò)線程數(shù)，并盡量做到網(wǎng)絡(luò)IO復(fù)用來降低線程創(chuàng)建消耗引起的系統(tǒng)高負(fù)載問題。此外，加上serviceExecutor: adaptive配置后，借助boost:asio網(wǎng)絡(luò)模塊實(shí)現(xiàn)網(wǎng)絡(luò)IO復(fù)用，同時(shí)實(shí)現(xiàn)網(wǎng)絡(luò)IO和磁盤IO分離。這樣高并發(fā)情況下，通過網(wǎng)絡(luò)鏈接IO復(fù)用和mongodb的鎖操作來控制磁盤IO訪問線程數(shù)，最終降低了大量線程創(chuàng)建和消耗帶來的高系統(tǒng)負(fù)載，最終通過該方式提升高并發(fā)讀寫性能。
2.2.3 網(wǎng)絡(luò)線程模型優(yōu)化前后性能對(duì)比
在該大流量集群中增加serviceExecutor: adaptive配置實(shí)現(xiàn)網(wǎng)絡(luò)IO復(fù)用及網(wǎng)絡(luò)IO與磁盤IO做分離后，該大流量集群時(shí)延大幅度降低，同時(shí)系統(tǒng)負(fù)載和慢日志也減少很多，具體如下:
2.2.3.1 優(yōu)化前后系統(tǒng)負(fù)載對(duì)比
驗(yàn)證方式：
該集群有多個(gè)分片，其中一個(gè)分片配置優(yōu)化后的主節(jié)點(diǎn)和同一時(shí)刻未優(yōu)化配置的主節(jié)點(diǎn)load負(fù)載比較： 未優(yōu)化配置的load
優(yōu)化配置的load
2.2.3.2 優(yōu)化前后慢日志對(duì)比
驗(yàn)證方式：
該集群有多個(gè)分片，其中一個(gè)分片配置優(yōu)化后的主節(jié)點(diǎn)和同一時(shí)刻未優(yōu)化配置的主節(jié)點(diǎn)慢日志數(shù)比較：
同一時(shí)間的慢日志數(shù)統(tǒng)計(jì)：
未優(yōu)化配置的慢日志數(shù)(19621)：
優(yōu)化配置后的慢日志數(shù)(5222):
2.2.3.3 優(yōu)化前后平均時(shí)延對(duì)比
驗(yàn)證方式：
該集群所有節(jié)點(diǎn)加上網(wǎng)絡(luò)IO復(fù)用配置后與默認(rèn)配置的平均時(shí)延對(duì)比如下:
從上圖可以看出，網(wǎng)絡(luò)IO復(fù)用后時(shí)延降低了1-2倍。
2.3 wiredtiger存儲(chǔ)引擎優(yōu)化
從上一節(jié)可以看出平均時(shí)延從200ms降低到了平均80ms左右，很顯然平均時(shí)延還是很高，如何進(jìn)一步提升性能降低時(shí)延?繼續(xù)分析集群，我們發(fā)現(xiàn)磁盤IO一會(huì)兒為0，一會(huì)兒持續(xù)性100%，并且有跌0現(xiàn)象，現(xiàn)象如下:
從圖中可以看出，I/O寫入一次性到2G，后面幾秒鐘內(nèi)I/O會(huì)持續(xù)性阻塞，讀寫I/O完全跌0，avgqu-sz、awit巨大，util次序性100%,在這個(gè)I/O跌0的過程中，業(yè)務(wù)方反應(yīng)的TPS同時(shí)跌0。
此外，在大量寫入IO后很長一段時(shí)間util又持續(xù)為0%，現(xiàn)象如下：
總體IO負(fù)載曲線如下:
從圖中可以看出IO很長一段時(shí)間持續(xù)為0%，然后又飆漲到100%持續(xù)很長時(shí)間，當(dāng)IO util達(dá)到100%后，分析日志發(fā)現(xiàn)又大量滿日志，同時(shí)mongostat監(jiān)控流量發(fā)現(xiàn)如下現(xiàn)象：
從上可以看出我們定時(shí)通過mongostat獲取某個(gè)節(jié)點(diǎn)的狀態(tài)的時(shí)候，經(jīng)常超時(shí)，超時(shí)的時(shí)候剛好是io util=100%的時(shí)候，這時(shí)候IO跟不上客戶端寫入速度造成阻塞。
有了以上現(xiàn)象，我們可以確定問題是由于IO跟不上客戶端寫入速度引起，第2章我們已經(jīng)做了mongodb服務(wù)層的優(yōu)化，現(xiàn)在我們開始著手wiredtiger存儲(chǔ)引擎層面的優(yōu)化，主要通過以下幾個(gè)方面：
1、cachesize調(diào)整
2、臟數(shù)據(jù)淘汰比例調(diào)整
3、checkpoint優(yōu)化
2.3.1 cachesize調(diào)整優(yōu)化(為何cacheSize越大性能越差)
前面的IO分析可以看出，超時(shí)時(shí)間點(diǎn)和I/O阻塞跌0的時(shí)間點(diǎn)一致，因此如何解決I/O跌0成為了解決改問題的關(guān)鍵所在。
找個(gè)集群平峰期(總tps50萬/s)查看當(dāng)時(shí)該節(jié)點(diǎn)的TPS，發(fā)現(xiàn)TPS不是很高，單個(gè)分片也就3-4萬左右，為何會(huì)有大量的刷盤，瞬間能夠達(dá)到10G/S，造成IO util持續(xù)性跌0(因?yàn)镮O跟不上寫入速度)。繼續(xù)分析wiredtiger存儲(chǔ)引擎刷盤實(shí)現(xiàn)原理，wiredtiger存儲(chǔ)引擎是一種B+樹存儲(chǔ)引擎，mongodb文檔首先轉(zhuǎn)換為KV寫入wiredtiger，在寫入過程中，內(nèi)存會(huì)越來越大，當(dāng)內(nèi)存中臟數(shù)據(jù)和內(nèi)存總占用率達(dá)到一定比例，就開始刷盤。同時(shí)當(dāng)達(dá)到checkpoint限制也會(huì)觸發(fā)刷盤操作，查看任意一個(gè)mongod節(jié)點(diǎn)進(jìn)程狀態(tài)，發(fā)現(xiàn)消耗的內(nèi)存過多，達(dá)到110G，如下圖所示:
于是查看mongod.conf配置文件，發(fā)現(xiàn)配置文件中配置的cacheSizeGB: 110G，可以看出，存儲(chǔ)引擎中KV總量幾乎已經(jīng)達(dá)到110G，按照5%臟頁開始刷盤的比例，峰值情況下cachesSize設(shè)置得越大，里面得臟數(shù)據(jù)就會(huì)越多，而磁盤IO能力跟不上臟數(shù)據(jù)得產(chǎn)生速度，這種情況很可能就是造成磁盤I/O瓶頸寫滿，并引起I/O跌0的原因。
此外，查看該機(jī)器的內(nèi)存，可以看到內(nèi)存總大小為190G，其中已經(jīng)使用110G左右，幾乎是mongod的存儲(chǔ)引起占用，這樣會(huì)造成內(nèi)核態(tài)的page cache減少，大量寫入的時(shí)候內(nèi)核cache不足就會(huì)引起磁盤缺頁中斷。
#FormatImgID_14#
解決辦法：通過上面的分析問題可能是大量寫入的場景，臟數(shù)據(jù)太多容易造成一次性大量I/O寫入，于是我們可以考慮把存儲(chǔ)引擎cacheSize調(diào)小到50G，來減少同一時(shí)刻I/O寫入的量，從而規(guī)避峰值情況下一次性大量寫入的磁盤I/O打滿阻塞問題。
2.3.2 存儲(chǔ)引擎dirty臟數(shù)據(jù)淘汰優(yōu)化
調(diào)整cachesize大小解決了5s請(qǐng)求超時(shí)問題，對(duì)應(yīng)告警也消失了，但是問題還是存在，5S超時(shí)消失了，1s超時(shí)問題還是偶爾會(huì)出現(xiàn)。
因此如何在調(diào)整cacheSize的情況下進(jìn)一步規(guī)避I/O大量寫的問題成為了問題解決的關(guān)鍵，進(jìn)一步分析存儲(chǔ)引擎原理，如何解決內(nèi)存和I/O的平衡關(guān)系成為了問題解決的關(guān)鍵，mongodb默認(rèn)存儲(chǔ)因?yàn)閣iredtiger的cache淘汰策略相關(guān)的幾個(gè)配置如下:
wiredtiger淘汰相關(guān)配置默認(rèn)值工作原理
eviction_target80當(dāng)用掉的內(nèi)存超過總內(nèi)存的百分比達(dá)到 eviction_target，后臺(tái)evict線程開始淘汰
eviction_trigger95當(dāng)用掉的內(nèi)存超過總內(nèi)存的 eviction_trigger，用戶線程也開始淘汰
eviction_dirty_target5當(dāng)cache中臟數(shù)據(jù)比例超過 eviction_dirty_target，后臺(tái)evict線程開始淘汰
eviction_dirty_trigger20當(dāng)cache中臟數(shù)據(jù)比例超過 eviction_dirty_trigger, 用戶線程也開始淘汰
evict.threads_min4后臺(tái)evict線程最小數(shù)
evict.threads_max4后臺(tái)evict線程最大數(shù)
調(diào)整cacheSize從120G到50G后，如果臟數(shù)據(jù)比例達(dá)到5%，則極端情況下如果淘汰速度跟不上客戶端寫入速度，這樣還是容易引起I/O瓶頸，最終造成阻塞。
解決辦法： 如何進(jìn)一步減少持續(xù)性I/O寫入，也就是如何平衡cache內(nèi)存和磁盤I/O的關(guān)系成為問題關(guān)鍵所在。從上表中可以看出，如果臟數(shù)據(jù)及總內(nèi)占用存達(dá)到一定比例，后臺(tái)線程開始選擇page進(jìn)行淘汰寫盤，如果臟數(shù)據(jù)及內(nèi)存占用比例進(jìn)一步增加，那么用戶線程就會(huì)開始做page淘汰，這是個(gè)非常危險(xiǎn)的阻塞過程，造成用戶請(qǐng)求驗(yàn)證阻塞。平衡cache和I/O的方法: 調(diào)整淘汰策略，讓后臺(tái)線程盡早淘汰數(shù)據(jù)，避免大量刷盤，同時(shí)降低用戶線程閥值，避免用戶線程進(jìn)行page淘汰引起阻塞。優(yōu)化調(diào)整存儲(chǔ)引起配置如下:
eviction_target: 75%
eviction_trigger：97%
eviction_dirty_target: %3
eviction_dirty_trigger：25%
evict.threads_min：8
evict.threads_max：12
總體思想是讓后臺(tái)evict盡量早點(diǎn)淘汰臟頁page到磁盤，同時(shí)調(diào)整evict淘汰線程數(shù)來加快臟數(shù)據(jù)淘汰，調(diào)整后mongostat及客戶端超時(shí)現(xiàn)象進(jìn)一步緩解。
2.3.3 存儲(chǔ)引擎checkpoint優(yōu)化調(diào)整
存儲(chǔ)引擎得checkpoint檢測點(diǎn)，實(shí)際上就是做快照，把當(dāng)前存儲(chǔ)引擎的臟數(shù)據(jù)全部記錄到磁盤。觸發(fā)checkpoint的條件默認(rèn)又兩個(gè)，觸發(fā)條件如下:
1、固定周期做一次checkpoint快照，默認(rèn)60
2、增量的redo log(也就是journal日志)達(dá)到2G
當(dāng)journal日志達(dá)到2G或者redo log沒有達(dá)到2G并且距離上一次時(shí)間間隔達(dá)到60s，wiredtiger將會(huì)觸發(fā)checkpoint，如果在兩次checkpoint的時(shí)間間隔類evict淘汰線程淘汰的dirty page越少，那么積壓的臟數(shù)據(jù)就會(huì)越多，也就是checkpoint的時(shí)候臟數(shù)據(jù)就會(huì)越多，造成checkpoint的時(shí)候大量的IO寫盤操作。如果我們把checkpoint的周期縮短，那么兩個(gè)checkpoint期間的臟數(shù)據(jù)相應(yīng)的也就會(huì)減少，磁盤IO 100%持續(xù)的時(shí)間也就會(huì)縮短。
checkpoint調(diào)整后的值如下:
checkpoint=(wait=25,log_size=1GB)
2.3.4 存儲(chǔ)引擎優(yōu)化前后IO對(duì)比
通過上面三個(gè)方面的存儲(chǔ)引擎優(yōu)化后，磁盤IO開始散列到各個(gè)不同的時(shí)間點(diǎn)，iostat監(jiān)控優(yōu)化后的IO負(fù)載如下:
從上面的io負(fù)載圖可以看出，之前的IO一會(huì)兒為0%，一會(huì)兒100%現(xiàn)象有所緩解，總結(jié)如下圖所示(注: 優(yōu)化后的IO曲線只是反應(yīng)大概趨勢，和真實(shí)趨勢有些出入):
2.3.5 存儲(chǔ)引擎優(yōu)化前后時(shí)延對(duì)比
優(yōu)化前后時(shí)延對(duì)比如下(注: 該集群有幾個(gè)業(yè)務(wù)同時(shí)使用，優(yōu)化前后時(shí)延對(duì)比如下):
從上圖可以看出，存儲(chǔ)引擎優(yōu)化后時(shí)間延遲進(jìn)一步降低并趨于平穩(wěn)，從平均80ms到平均20ms左右，但是還是不完美，有抖動(dòng)。
3 服務(wù)器系統(tǒng)磁盤IO問題解決
3.1 服務(wù)器IO硬件問題背景
如第前面章節(jié)所述，當(dāng)wiredtiger大量淘汰數(shù)據(jù)時(shí)，發(fā)現(xiàn)只要每秒磁盤寫入量超過500M/s，接下來的幾秒鐘內(nèi)util就會(huì)持續(xù)100%，w/s幾乎跌0，于是開始懷疑磁盤硬件存在缺陷。如下圖所示：
從上圖可以看出磁盤為nvMe的ssd盤，查看相關(guān)數(shù)據(jù)可以看出該盤IO性能很好，支持每秒2G寫入，iops能達(dá)到15萬，而我們線上的盤只能每秒寫入最多500M。
3.2 服務(wù)器IO硬件問題解決后性能對(duì)比
通過大量的線下測試以及服務(wù)器廠商的配合，nvme的ssd io瓶頸問題得以解決，經(jīng)過和廠商確認(rèn)分析，最終定位到IO問題是linux內(nèi)核版本不匹配引起，如果大家nvme ssd盤有同樣問題，記得升級(jí)linux版本到3.10.0-957.27.2.el7.x86_64版本，升級(jí)后nvme ssd的IO能力達(dá)到近2G/s寫入。
說明: 從本節(jié)開始，我們的服務(wù)器分為兩種：1. 低IO服務(wù)器，也就是沒有做操作系統(tǒng)升級(jí)的服務(wù)器，IO寫入能力500M/s，2. 高IO服務(wù)器，也就是操作系統(tǒng)升級(jí)后的服務(wù)器，IO寫入能力近2G/s.。
于是考慮把該分片集群的主節(jié)點(diǎn)全部遷移到操作系統(tǒng)升級(jí)后的高IO服務(wù)器(為了謹(jǐn)慎，我們只替換了分片主節(jié)點(diǎn)，從節(jié)點(diǎn)還是老的未升級(jí)的低IO服務(wù)器)，該服務(wù)器io寫入能達(dá)到近2G/s(注意:只遷移了主節(jié)點(diǎn)，從節(jié)點(diǎn)還是在之前的IO-500M/s的低IO服務(wù)器)，具體的操作過程在后面章節(jié)會(huì)描述，詳見3.3章節(jié)。遷移完成后，發(fā)現(xiàn)性能得到了進(jìn)一步提升，時(shí)延遲降低到平均2-4ms/s，幾個(gè)不同業(yè)務(wù)接口看到的時(shí)延監(jiān)控如下圖所示：
從上圖時(shí)延可以看出，遷移主節(jié)點(diǎn)到操作系統(tǒng)升級(jí)后的高IO機(jī)器后，時(shí)延進(jìn)一步降低到平均2-4ms。
雖然時(shí)延降低到了平均2-4ms，但是還是有很多幾十ms的尖刺，因此我們需要進(jìn)一步的優(yōu)化分析。
3.3 硬件問題回顧及遺留問題
在前面的分析中，我們在定位nvme ssd硬件IO問題的過程中，和廠商一起分析發(fā)現(xiàn)IO問題是由于操作系統(tǒng)版本不對(duì)引起，于是開始對(duì)線上的主從mongod實(shí)例的服務(wù)器硬件進(jìn)行升級(jí)，升級(jí)后開始替換線上該集群的實(shí)例。具體操作過程如下:
1、為了驗(yàn)證IO升級(jí)后的機(jī)器，我們替換一個(gè)分片的從節(jié)點(diǎn)為升級(jí)操作系統(tǒng)后的高IO服務(wù)器(IO問題得以解決，IO能力從之前的500M/s寫入達(dá)到了近2G/s，我們稱IO升級(jí)后的服務(wù)器為高IO服務(wù)器，未升級(jí)的服務(wù)器為低IO服務(wù)器)，替換后通過iostat可以看到該從節(jié)點(diǎn)的IO 100%問題得到了很大程度的緩解，不會(huì)出現(xiàn)持續(xù)性IO跌0問題。
2、在第1步的從節(jié)點(diǎn)在高IO服務(wù)器跑了一周后，我們確定升級(jí)后的高IO服務(wù)器運(yùn)行穩(wěn)定，為了謹(jǐn)慎起見，我們雖然確定該高IO服務(wù)器在從節(jié)點(diǎn)運(yùn)行沒有問題，但是我們需要進(jìn)一步在主節(jié)點(diǎn)驗(yàn)證是否穩(wěn)定，于是我們做了一次主從切換，該高IO服務(wù)器變?yōu)橹鞴?jié)點(diǎn)運(yùn)行，也就是集群中某個(gè)分片的主節(jié)點(diǎn)服務(wù)器變?yōu)榱烁逫O服務(wù)器，但是從節(jié)點(diǎn)還是低IO服務(wù)器。
3、當(dāng)?shù)?步的主節(jié)點(diǎn)在高IO服務(wù)器跑了數(shù)周后，我們確定主節(jié)點(diǎn)在高IO服務(wù)器運(yùn)行正常，于是我們得下結(jié)論: 升級(jí)后的服務(wù)器運(yùn)行穩(wěn)定。
4、確定高IO服務(wù)器沒問題后，我們開始批量替換mongod實(shí)例到該服務(wù)器。為了保險(xiǎn)起見，畢竟只驗(yàn)證了一臺(tái)高IO服務(wù)器在主從運(yùn)行都沒問題，于是我們考慮只把整個(gè)集群的主節(jié)點(diǎn)替換為高IO服務(wù)器(當(dāng)時(shí)我認(rèn)為客戶端都是用的默認(rèn)配置，數(shù)據(jù)寫到主節(jié)點(diǎn)就會(huì)返回OK，雖然從節(jié)點(diǎn)IO慢，但是還是可以追上oplog速度的，這樣客戶端時(shí)延不會(huì)因?yàn)橐郧爸鞴?jié)點(diǎn)IO有問題而抖動(dòng))。
為了謹(jǐn)慎保險(xiǎn)起見，通過上面的硬件替換升級(jí)過程，我們只替換了所有分片的主節(jié)點(diǎn)，替換升級(jí)前后架構(gòu)發(fā)生了變化，原有集群硬件架構(gòu)如下圖所示：
所有分片主節(jié)點(diǎn)硬件升級(jí)后的架構(gòu)圖如下圖所示：
從上圖可知，新的集群架構(gòu)，主從節(jié)點(diǎn)服務(wù)器IO能力有比較大的差距。最開始我認(rèn)為業(yè)務(wù)方默認(rèn)沒有設(shè)置WriteConncern，也就是默認(rèn)寫入到Primary就向客戶端發(fā)送確認(rèn)，因此不會(huì)影響業(yè)務(wù)寫入。
所有分片主節(jié)點(diǎn)升級(jí)為高IO服務(wù)器后，多個(gè)業(yè)務(wù)接口的時(shí)間訪問延遲降到了平均2-4ms左右，但是在超大流量沖擊的時(shí)候，還是有幾十ms的尖刺，我選取一個(gè)抖動(dòng)比較典型的接口時(shí)延為例，如下圖所示：
從上圖可以看出，特別是在大流量沖擊的時(shí)間點(diǎn)，尖刺越明顯。
主節(jié)點(diǎn)硬件升級(jí)后續(xù)優(yōu)化
4.1 readConcern配置優(yōu)化
在上一節(jié)，我們替換了分片的所有主節(jié)點(diǎn)為高IO服務(wù)器，從節(jié)點(diǎn)還是以前未升級(jí)的低IO服務(wù)器。由于業(yè)務(wù)方默認(rèn)沒有設(shè)置WriteConncern，因此認(rèn)為客戶端寫到主成功就會(huì)返回客戶端OK，即使從服務(wù)器性能差也不會(huì)影響客戶端寫主。
在升級(jí)主服務(wù)器后，我繼續(xù)優(yōu)化存儲(chǔ)引擎把eviction_dirty_trigger：25%調(diào)整到了30%。
由于受到超大流量的高并發(fā)沖擊，會(huì)從平峰期的幾十萬TPS瞬間飆升到百萬級(jí)別，而且該毛刺幾乎每天都會(huì)出現(xiàn)好幾次，比較容易復(fù)現(xiàn)。于是提前部署好mongostat監(jiān)控所有實(shí)例，同時(shí)在每個(gè)服務(wù)器上用Iostat監(jiān)控實(shí)時(shí)的IO狀況，同時(shí)編寫腳本實(shí)時(shí)采集db.serverstatus()、db.printSlaveReplicationInfo()、db.printReplicationInfo()等集群重要信息。
當(dāng)某個(gè)時(shí)間點(diǎn)監(jiān)控出現(xiàn)毛刺后，于是開始分析mongostat，我們發(fā)現(xiàn)一個(gè)問題，即使在平峰期，臟數(shù)據(jù)比例也會(huì)持續(xù)增長到閥值(30%)，我們知道當(dāng)臟數(shù)據(jù)比例超過eviction_dirty_trigger：30%閥值，用戶線程就會(huì)進(jìn)行evict淘汰，這樣用戶線程就會(huì)阻塞直到騰出內(nèi)存空間，因此淘汰刷盤過程業(yè)務(wù)訪問很慢。分析平峰期毛刺時(shí)間點(diǎn)對(duì)應(yīng)的mongostat監(jiān)控，發(fā)現(xiàn)如下情況:
從上圖可以看出，集群TPS才40-50萬左右的時(shí)候某個(gè)分片的主節(jié)點(diǎn)出現(xiàn)了臟數(shù)據(jù)達(dá)到eviction_dirty_trigger：30%閥值，于是整個(gè)集群訪問時(shí)延就會(huì)瞬間增加，原因是一個(gè)分片的用戶線程需要刷盤，導(dǎo)致這個(gè)分片的訪問時(shí)延上升(實(shí)際上其他分片的訪問時(shí)延還是正常的)，最終把整體平均時(shí)延拉上去了。
為什么普通平峰期也會(huì)有抖動(dòng)？這很明顯不科學(xué)。
于是獲取出問題的主節(jié)點(diǎn)的一些監(jiān)控信息，得出以下結(jié)論：
1、IO正常，IO不是瓶頸。
2、分析抖動(dòng)的時(shí)候的系統(tǒng)top負(fù)載，負(fù)載正常。
3、該分片的TPS才4萬左右，顯然沒到到分片峰值。
4、db.printSlaveReplicationInfo()看到主從延遲較高。
當(dāng)客戶端時(shí)延監(jiān)控發(fā)現(xiàn)時(shí)間延遲尖刺后，我們發(fā)現(xiàn)主節(jié)點(diǎn)所有現(xiàn)象一切正常，系統(tǒng)負(fù)載、IO、TPS等都沒有到達(dá)瓶頸，但是有一個(gè)唯一的異常，就是主從同步延遲持續(xù)性增加，如下圖所示：
同時(shí)對(duì)應(yīng)低IO服務(wù)器的從節(jié)點(diǎn)上面的io狀況如下圖:
從節(jié)點(diǎn)的IO性能一塌烏涂，這也正是主從延遲增加的根源。
從上圖可以看出在時(shí)延尖刺的同樣時(shí)間點(diǎn)，主從延遲超大。于是懷疑時(shí)延尖刺可能和從節(jié)點(diǎn)拉取Oplog速度有關(guān)系，于是把整個(gè)mongostat、iostat、top、db.printSlaveReplicationInfo()、db.serverstatus()等監(jiān)控持續(xù)跑了兩天，記錄下了兩天內(nèi)的一些核心系統(tǒng)和mongo監(jiān)控指標(biāo)。
兩天后，對(duì)著客戶端時(shí)延尖刺時(shí)間點(diǎn)分析對(duì)應(yīng)監(jiān)控?cái)?shù)據(jù)，發(fā)現(xiàn)一個(gè)共同的現(xiàn)象，尖刺出現(xiàn)時(shí)間點(diǎn)和臟數(shù)據(jù)eviction_dirty_trigger超過閥值時(shí)間點(diǎn)一致，同時(shí)主從延遲在這個(gè)時(shí)間點(diǎn)都有很大的延遲。
到這里，我越來越懷疑問題和從節(jié)點(diǎn)拉取oplog速度有關(guān)。之前認(rèn)為業(yè)務(wù)方默認(rèn)沒有設(shè)置WriteConncern，也就是默認(rèn)寫入到Primary就向客戶端發(fā)送確認(rèn)，可能應(yīng)答客戶端前還有其他流程會(huì)影響服務(wù)的返回OK給客戶端。于是查看官方mongodb-3.6的Production Notes，從中發(fā)現(xiàn)了如下信息：
從Production Notes可以看出，mongodb-3.6默認(rèn)啟用了 read concern "majority"功能，于是懷疑抖動(dòng)可能和該功能有關(guān)。為了避免臟讀，mongodb增加了該功能，啟用該功能后，mongodb為了確保帶有帶有參數(shù)readConcern("Majority")的客戶端讀取到的數(shù)據(jù)確實(shí)是同步到大多數(shù)實(shí)例的數(shù)據(jù)，因此mongodb必須在內(nèi)存中借助snapshot 及主從通信來維護(hù)更多的版本信息，這就增加了wiredtiger存儲(chǔ)引擎對(duì)內(nèi)存的需求。由于從節(jié)點(diǎn)是低IO服務(wù)器，很容易造成阻塞，這樣拉取oplog的速度就會(huì)跟不上進(jìn)度，造成主節(jié)點(diǎn)消耗大量的內(nèi)存來維護(hù)快照信息，這樣就會(huì)導(dǎo)致大量的內(nèi)存消耗，最終導(dǎo)致臟數(shù)據(jù)瞬間劇增，很快達(dá)到eviction_dirty_trigger閥值，業(yè)務(wù)也因此抖動(dòng)。
說一個(gè)小插曲，因?yàn)閙ongodb-3.6默認(rèn)開啟enableMajorityReadConcern功能，我們在這個(gè)過程中出現(xiàn)過幾次嚴(yán)重的集群故障，業(yè)務(wù)流量有段時(shí)間突然暴漲，造成時(shí)延持續(xù)性達(dá)到幾千ms，寫入全部阻塞，現(xiàn)象如下:
該問題的根源也是因?yàn)閑nableMajorityReadConcern功能引起，由于從節(jié)點(diǎn)嚴(yán)重落后主節(jié)點(diǎn)，導(dǎo)致主節(jié)點(diǎn)為了維護(hù)各種snapshot快照，消耗大量內(nèi)存，同時(shí)從節(jié)點(diǎn)和主節(jié)點(diǎn)的oplog延后，導(dǎo)致主節(jié)點(diǎn)維護(hù)了更多的內(nèi)存版本，臟數(shù)據(jù)比例持續(xù)性增長，直到從節(jié)點(diǎn)追上oplog。由于我們的業(yè)務(wù)不需要readConcert功能，因此我們考慮禁用該功能(配置文件增加配置replication.enableMajorityReadConcern=false)。
鑒于篇幅，enableMajorityReadConcern及主從硬件IO能力不足引起的嚴(yán)重業(yè)務(wù)故障，本篇不做詳細(xì)的分析，后期會(huì)寫一篇專門的《百萬級(jí)高并發(fā)mongodb集群性能優(yōu)化采坑記》中做分享，除了ReadConcern采坑，還有其他好幾個(gè)核心采坑點(diǎn)，敬請(qǐng)關(guān)注。
此外，后續(xù)會(huì)專門寫一篇ReadConcern的原理及代碼實(shí)現(xiàn)分析文章，敬請(qǐng)關(guān)注。
4.2 替換從節(jié)點(diǎn)服務(wù)器為升級(jí)后的高IO服務(wù)器
除了通過replication.enableMajorityReadConcern=false在配置文件中禁用ReadConcern Majority功能，我們繼續(xù)把所有分片的從節(jié)點(diǎn)由之前的低IO服務(wù)器替換為升級(jí)后的高IO服務(wù)器，升級(jí)后所有主從硬件資源性能完全一樣，升級(jí)后集群分片架構(gòu)如下圖所示：
通過禁用enableMajorityReadConcern功能，并統(tǒng)一主從服務(wù)器硬件資源后，查看有抖動(dòng)的一個(gè)接口的時(shí)間延遲，如下圖所示：
從上圖可以看出，通過MajorityReadConcern功能并且替把所有從節(jié)點(diǎn)的低IO服務(wù)器做系統(tǒng)升級(jí)后，業(yè)務(wù)時(shí)間延遲抖動(dòng)的峰值進(jìn)一步降低了，從平均2-4ms降低到了1ms左右，同時(shí)，峰值毛刺從前面第3節(jié)中的80ms降低到了現(xiàn)在的峰值40ms左右。
此外，4.1節(jié)提到的臟數(shù)據(jù)持續(xù)性突破eviction_dirty_trigger閥值引起客戶端時(shí)延飆漲到幾千ms的問題得以徹底解決。
總結(jié): MajorityReadConcern功能禁用并升級(jí)從節(jié)點(diǎn)到高IO服務(wù)器后，總體收益如下：
1、平均時(shí)延從2-4ms降低到1ms左右
2、峰值時(shí)延毛刺從80ms降低到40ms
3、之前出現(xiàn)的臟數(shù)據(jù)比例突破30%飆漲到50%的問題徹底解決。
4、尖刺持續(xù)時(shí)間變短
4.3 繼續(xù)優(yōu)化調(diào)整存儲(chǔ)引起參數(shù)
通過前面的條優(yōu)化，我們發(fā)現(xiàn)有一個(gè)業(yè)務(wù)接口還是偶爾有40ms時(shí)延尖刺，分析發(fā)現(xiàn)主要是eviction_dirty_trigger達(dá)到了我們配置的閥值，業(yè)務(wù)線程開始淘汰page cache，這樣就造成業(yè)務(wù)線程很慢，最終導(dǎo)致平均時(shí)延尖刺。
為了進(jìn)一步減緩時(shí)延尖刺，我們繼續(xù)在之前基礎(chǔ)上對(duì)存儲(chǔ)引擎調(diào)優(yōu)，調(diào)整后配置如下：
eviction_target: 75%
eviction_trigger：97%
eviction_dirty_target: %3
eviction_dirty_trigger：30%
evict.threads_min：14
evict.threads_max：18
checkpoint=(wait=20,log_size=1GB)
經(jīng)過此輪的存儲(chǔ)引擎調(diào)優(yōu)后，該業(yè)務(wù)的核心接口時(shí)延進(jìn)一步好轉(zhuǎn)，時(shí)延尖刺相比之前有了進(jìn)一步的改善，時(shí)延最大尖刺時(shí)間從前面的45ms降低到了35ms，同時(shí)尖刺出現(xiàn)的頻率明顯降低了，如下圖所示:
從此圖可以看出，在個(gè)別時(shí)間點(diǎn)還是有一次時(shí)延尖刺，對(duì)照該尖刺的時(shí)間點(diǎn)分析提前部署好的mongostat和iostat監(jiān)控，得到如下信息：
從上圖可以看出，在峰值TPS百萬級(jí)別的時(shí)候，部分節(jié)點(diǎn)evict淘汰速率已經(jīng)跟不上寫入速度，因此出現(xiàn)了用戶線程刷盤的情況。
在這個(gè)時(shí)間點(diǎn)分析對(duì)應(yīng)機(jī)器的系統(tǒng)負(fù)載、磁盤io狀況、內(nèi)存狀況等，發(fā)現(xiàn)系統(tǒng)負(fù)載、比較正常，但是對(duì)應(yīng)服務(wù)器磁盤IO偏高，如下圖所示：
同時(shí)分析對(duì)應(yīng)服務(wù)器對(duì)應(yīng)時(shí)間點(diǎn)的慢日志，我們發(fā)現(xiàn)尖刺出現(xiàn)時(shí)間的的慢日志統(tǒng)計(jì)如下：
分析非時(shí)延尖刺時(shí)間點(diǎn)，對(duì)應(yīng)慢日志統(tǒng)計(jì)如下:
分析兩個(gè)時(shí)間點(diǎn)慢日志可以看出，慢日志出現(xiàn)的條數(shù)和時(shí)間延遲尖刺出現(xiàn)的時(shí)間點(diǎn)一致，也就是磁盤IO負(fù)載很高的時(shí)候。
結(jié)論：通過上面的分析可以看出，當(dāng)磁盤IO比較高(util超過50%)的時(shí)候，慢日志和時(shí)延都會(huì)增加，他們之間成正比關(guān)系，IO依然時(shí)性能瓶頸點(diǎn)。
疑問：量高的時(shí)候通過調(diào)整存儲(chǔ)引擎evict和checkpoint配置，IO寫入分散到了不同時(shí)間點(diǎn)，相比以起集中再一個(gè)時(shí)間點(diǎn)寫入有了很大改善。但是，還是會(huì)出現(xiàn)部分時(shí)間點(diǎn)IO寫入接近為0，其他時(shí)間點(diǎn)IO 100%的現(xiàn)象。
5.總結(jié)
通過軟件層面(mongodb服務(wù)配置、業(yè)務(wù)優(yōu)化、存儲(chǔ)引擎優(yōu)化)及硬件系統(tǒng)優(yōu)化(升級(jí)操作系統(tǒng))后，該大流量集群的核心接口時(shí)延從最初的平均成百上千ms降低到了現(xiàn)在的平均1-2ms，性能提升比較可觀，整體時(shí)延性能提升數(shù)十倍。
優(yōu)化前主要業(yè)務(wù)接口時(shí)延：
在不增加物理服務(wù)器資源的基礎(chǔ)上，經(jīng)過一系列的優(yōu)化措施，最終業(yè)務(wù)方主要接口時(shí)延控制到了幾ms，如下圖所示：
6.遺留問題
如4.3分析所述，當(dāng)峰值tps持續(xù)性達(dá)到100萬左右的時(shí)候，有明顯的磁盤IO問題，但是IO寫入在不同時(shí)間點(diǎn)很不均衡，有時(shí)候在流量持續(xù)性高峰期存在如下現(xiàn)象(注: 下圖只是大概反應(yīng)高峰期持續(xù)性寫入的IO趨勢狀況)：
如上圖所示，有時(shí)候高峰期不同時(shí)間點(diǎn)磁盤IO不均衡，如果我們能把IO平均散列到各個(gè)不同時(shí)間點(diǎn)，這樣或許可以解決IO瓶頸問題。我試著通過繼續(xù)調(diào)大evict線程數(shù)來達(dá)到目的，但是當(dāng)線程數(shù)超過一定值后效果不明顯。后續(xù)會(huì)持續(xù)分析wiredtiger存儲(chǔ)引擎代碼實(shí)現(xiàn)來了解整個(gè)機(jī)制，分析有時(shí)候磁盤IO嚴(yán)重分布不均衡代碼實(shí)現(xiàn)原理。
7. 后續(xù)相關(guān)分享
近期繼續(xù)分享如下主題，敬請(qǐng)關(guān)注：
《百萬級(jí)高并發(fā)mongodb集群性能優(yōu)化采坑記》
《線上典型集群抖動(dòng)、不可用等問題匯總分析》
《Mongodb文檔數(shù)據(jù)庫業(yè)務(wù)使用最佳案例分享》
《Mongodb-3.6網(wǎng)絡(luò)IO線程模型設(shè)計(jì)及代碼實(shí)現(xiàn)》
注意
文章中的一些優(yōu)化方法并不是一定適用于所有mongodb場景，請(qǐng)根據(jù)實(shí)際業(yè)務(wù)場景和硬件物理資源進(jìn)行優(yōu)化，而不要按部就班。
作者簡介
楊亞洲，前滴滴出行技術(shù)專家，現(xiàn)任Oppo文檔數(shù)據(jù)庫研發(fā)負(fù)責(zé)人，一直專注于分布式緩存、高性能服務(wù)器、分布式存儲(chǔ)、數(shù)據(jù)庫、中間件等相關(guān)研發(fā)，后續(xù)會(huì)持續(xù)分析Mongodb內(nèi)核、wiredtiger存儲(chǔ)引擎、rocksdb存儲(chǔ)引擎源碼及，相關(guān)分享會(huì)發(fā)布到我的git賬號(hào)。Github賬號(hào)地址: https://github.com/y123456yz 郵箱:yangyazhou#oppo.com
Oppo公司互聯(lián)網(wǎng)服務(wù)簡介
可能外界對(duì)Oppo的認(rèn)識(shí)僅僅停留在手機(jī)業(yè)務(wù)，這是一種誤解。Oppo的互聯(lián)網(wǎng)業(yè)務(wù)流量絕不輸于部分一線互聯(lián)網(wǎng)公司，歡迎加入Oppo互聯(lián)網(wǎng)運(yùn)維云存儲(chǔ)團(tuán)隊(duì)參與公司百萬級(jí)高并發(fā)文檔數(shù)據(jù)庫研發(fā)。
