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