百萬級高并發mongodb叢集性能數十倍提升優化實踐(上篇)

關于作者

  前滴滴出行技術專家，現任OPPO文檔資料庫mongodb負責人，負責oppo千萬級峰值TPS/十萬億級資料量文檔資料庫mongodb研發和運維工作，一直專注于分布式緩存、高性能服務端、資料庫、中間件等相關研發。後續持續分享《MongoDB核心源碼設計、性能優化、最佳運維實踐》，mongodb源碼中文注釋分析：

https://github.com/y123456yz/reading-and-annotate-mongodb-3.6

1.背景

  線上某叢集峰值TPS超過100萬/秒左右(主要為寫流量，讀流量很低)，峰值tps幾乎已經到達叢集上限，同時平均時延也超過100ms，随着讀寫流量的進一步增加，時延抖動嚴重影響業務可用性。該叢集采用mongodb天然的分片模式架構，資料均衡的分布于各個分片中，添加片鍵啟用分片功能後實作完美的負載均衡。叢集每個節點流量監控如下圖所示:

  從上圖可以看出叢集流量比較大，峰值已經突破120萬/秒，其中delete過期删除的流量不算在總流量裡面(delete由主觸發删除，但是主上面不會顯示，隻會在從節點拉取oplog的時候顯示)。如果算上主節點的delete流量，總tps超過150萬/秒。

2.軟體優化

  在不增加伺服器資源的情況下，首先做了如下軟體層面的優化，并取得了理想的數倍性能提升：

1.業務層面優化

2.Mongodb配置優化

3.存儲引擎優化

2.1 業務層面優化

  該叢集總文檔數百億條，每條文檔記錄預設儲存三天，業務随機散列資料到三天後任意時間點随機過期淘汰。由于文檔數目很多，白天平峰監控可以發現從節點經常有大量delete操作，甚至部分時間點delete删除操作數已經超過了業務方讀寫流量，是以考慮把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在三天後的淩晨任意時間點，即可規避白天高峰期觸發過期索引引入的叢集大量delete，進而降低了高峰期叢集負載，最終減少業務平均時延及抖動。

  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!"})           

2.在expireAt指定的時間往後推遲expireAfterSeconds秒過期，也就是目前時間往後推遲60秒過期

db.log_events.insert( {"createdAt": new Date(),"logEvent": 2,"logMessage": "Success!"} )
Db.collection.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 60 } )           

  Delete過期Tips2: 為何mongostat  隻能監控到從節點有delete操作，主節點沒有？

原因是過期索引隻在master主節點觸發，觸發後主節點會直接删除調用對應wiredtiger存儲引擎接口做删除操作，不會走正常的用戶端連結處理流程，是以主節點上看不到delete統計。

  主節點過期delete後會生存對于的delete oplog資訊，從節點通過拉取主節點oplog然後模拟對于client回放，這樣就保證了主資料删除的同時從資料也得以删除，保證資料最終一緻性。從節點模拟client回放過程将會走正常的client連結過程，是以會記錄delete count統計，詳見如下代碼:

  官方參考如下:

https://docs.mongodb.com/manual/tutorial/expire-data/

2.2 Mongodb配置優化(網絡IO複用，網絡IO和磁盤IO做分離)

  由于叢集tps高，同時整點有大量推送，是以整點并發會更高，mongodb預設的一個請求一個線程這種模式将會嚴重影響系統負載，該預設配置不适合高并發的讀寫應用場景。官方介紹如下:

2.2.1 Mongodb内部網絡線程模型實作原理

  mongodb預設網絡模型架構是一個用戶端連結，mongodb會建立一個線程處理該連結fd的所有讀寫請求及磁盤IO操作。

  Mongodb預設網絡線程模型不适合高并發讀寫原因如下:

  1. 在高并發的情況下，瞬間就會建立大量的線程，例如線上的這個叢集，連接配接數會瞬間增加到1萬左右，也就是作業系統需要瞬間建立1萬個線程，這樣系統load負載就會很高。

  2. 此外，當連結請求處理完，進入流量低峰期的時候，用戶端連接配接池回收連結，這時候mongodb服務端就需要銷毀線程，這樣進一步加劇了系統負載，同時進一步增加了資料庫的抖動，特别是在PHP這種短連結業務中更加明顯，頻繁的建立線程銷毀線程造成系統高負債。

  3. 一個連結一個線程，該線程除了負責網絡收發外，還負責寫資料到存儲引擎，整個網絡I/O處理和磁盤I/O處理都由同一個線程負責，本身架構設計就是一個缺陷。

2.2.2 網絡線程模型優化方法

  為了适應高并發的讀寫場景，mongodb-3.6開始引入serviceExecutor: adaptive配置，該配置根據請求數動态調整網絡線程數，并盡量做到網絡IO複用來降低線程建立消耗引起的系統高負載問題。此外，加上serviceExecutor: adaptive配置後，借助boost:asio網絡子產品實作網絡IO複用，同時實作網絡IO和磁盤IO分離。這樣高并發情況下，通過網絡連結IO複用和mongodb的鎖操作來控制磁盤IO通路線程數，最終降低了大量線程建立和消耗帶來的高系統負載，最終通過該方式提升高并發讀寫性能。

2.2.3 網絡線程模型優化前後性能對比

  在該大流量叢集中增加serviceExecutor: adaptive配置實作網絡IO複用及網絡IO與磁盤IO做分離後，該大流量叢集時延大幅度降低，同時系統負載和慢日志也減少很多，具體如下:

2.2.3.1 優化前後系統負載對比

驗證方式：

1.該叢集有多個分片，其中一個分片配置優化後的主節點和同一時刻未優化配置的主節點load負載比較：

未優化配置的load

優化配置的load

2.2.3.2 優化前後慢日志對比

  該叢集有多個分片，其中一個分片配置優化後的主節點和同一時刻未優化配置的主節點慢日志數比較：

同一時間的慢日志數統計：

  未優化配置的慢日志數(19621)：

  優化配置後的慢日志數(5222):

2.2.3.3 優化前後平均時延對比

  該叢集所有節點加上網絡IO複用配置後與預設配置的平均時延對比如下:

  從上圖可以看出，網絡IO複用後時延降低了1-2倍。

2.3 wiredtiger存儲引擎優化

  從上一節可以看出平均時延從200ms降低到了平均80ms左右，很顯然平均時延還是很高，如何進一步提升性能降低延遲時間？繼續分析叢集，我們發現磁盤IO一會兒為0，一會兒持續性100%，并且有跌0現象，現象如下:

  從圖中可以看出，I/O寫入一次性到2G，後面幾秒鐘内I/O會持續性阻塞，讀寫I/O完全跌0，avgqu-sz、awit巨大，util次序性100%,在這個I/O跌0的過程中，業務方反應的TPS同時跌0。

  此外，在大量寫入IO後很長一段時間util又持續為0%，現象如下：

  總體IO負載曲線如下:

  從圖中可以看出IO很長一段時間持續為0%，然後又飙漲到100%持續很長時間，當IO util達到100%後，分析日志發現又大量滿日志，同時mongostat監控流量發現如下現象：

  從上可以看出我們定時通過mongostat擷取某個節點的狀态的時候，經常逾時，逾時的時候剛好是io util=100%的時候，這時候IO跟不上用戶端寫入速度造成阻塞。

  有了以上現象，我們可以确定問題是由于IO跟不上用戶端寫入速度引起，第2章我們已經做了mongodb服務層的優化，現在我們開始着手wiredtiger存儲引擎層面的優化，主要通過以下幾個方面：

  1.cachesize調整

  2.髒資料淘汰比例調整

  3.checkpoint優化

2.3.1 cachesize調整優化(為何cacheSize越大性能越差)

  前面的IO分析可以看出，逾時時間點和I/O阻塞跌0的時間點一緻，是以如何解決I/O跌0成為了解決改問題的關鍵所在。

  找個叢集平峰期(總tps50萬/s)檢視當時該節點的TPS，發現TPS不是很高，單個分片也就3-4萬左右，為何會有大量的刷盤，瞬間能夠達到10G/S，造成IO util持續性跌0(因為IO跟不上寫入速度)。繼續分析wiredtiger存儲引擎刷盤實作原理，wiredtiger存儲引擎是一種B+樹存儲引擎，mongodb文檔首先轉換為KV寫入wiredtiger，在寫入過程中，記憶體會越來越大，當記憶體中髒資料和記憶體總占用率達到一定比例，就開始刷盤。同時當達到checkpoint限制也會觸發刷盤操作，檢視任意一個mongod節點程序狀态，發現消耗的記憶體過多，達到110G，如下圖所示:

  于是檢視mongod.conf配置檔案，發現配置檔案中配置的cacheSizeGB: 110G，可以看出，存儲引擎中KV總量幾乎已經達到110G，按照5%髒頁開始刷盤的比例，峰值情況下cachesSize設定得越大，裡面得髒資料就會越多，而磁盤IO能力跟不上髒資料得産生速度，這種情況很可能就是造成磁盤I/O瓶頸寫滿，并引起I/O跌0的原因。

  此外，檢視該機器的記憶體，可以看到記憶體總大小為190G，其中已經使用110G左右，幾乎是mongod的存儲引起占用，這樣會造成核心态的page cache減少，大量寫入的時候核心cache不足就會引起磁盤缺頁中斷，引起大量的寫盤。

  解決辦法：通過上面的分析問題可能是大量寫入的場景，髒資料太多容易造成一次性大量I/O寫入，于是我們可以考慮把存儲引起cacheSize調小到50G，來減少同一時刻I/O寫入的量，進而規避峰值情況下一次性大量寫入的磁盤I/O打滿阻塞問題。

2.3.2 存儲引擎dirty髒資料淘汰優化

  調整cachesize大小解決了5s請求逾時問題，對應告警也消失了，但是問題還是存在，5S逾時消失了，1s逾時問題還是偶爾會出現。

  是以如何在調整cacheSize的情況下進一步規避I/O大量寫的問題成為了問題解決的關鍵，進一步分析存儲引擎原理，如何解決記憶體和I/O的平衡關系成為了問題解決的關鍵，mongodb預設存儲因為wiredtiger的cache淘汰政策相關的幾個配置如下:

  調整cacheSize從120G到50G後，如果髒資料比例達到5%，則極端情況下如果淘汰速度跟不上用戶端寫入速度，這樣還是容易引起I/O瓶頸，最終造成阻塞。

  解決辦法： 如何進一步減少持續性I/O寫入，也就是如何平衡cache記憶體和磁盤I/O的關系成為問題關鍵所在。從上表中可以看出，如果髒資料及總内占用存達到一定比例，背景線程開始選擇page進行淘汰寫盤，如果髒資料及記憶體占用比例進一步增加，那麼使用者線程就會開始做page淘汰，這是個非常危險的阻塞過程，造成使用者請求驗證阻塞。平衡cache和I/O的方法: 調整淘汰政策，讓背景線程盡早淘汰資料，避免大量刷盤，同時降低使用者線程閥值，避免使用者線程進行page淘汰引起阻塞。優化調整存儲引起配置如下:

  eviction_target: 75%

  eviction_trigger：97%

  eviction_dirty_target: %3

  eviction_dirty_trigger：25%

  evict.threads_min：8

  evict.threads_min：12

  總體思想是讓背景evict盡量早點淘汰髒頁page到磁盤，同時調整evict淘汰線程數來加快髒資料淘汰，調整後mongostat及用戶端逾時現象進一步緩解。

2.3.3 存儲引擎checkpoint優化調整

  存儲引擎得checkpoint檢測點，實際上就是做快照，把目前存儲引擎的髒資料全部記錄到磁盤。觸發checkpoint的條件預設又兩個，觸發條件如下:

  1.固定周期做一次checkpoint快照，預設60s

  2.增量的redo log(也就是journal日志)達到2G

  當journal日志達到2G或者redo log沒有達到2G并且距離上一次時間間隔達到60s，wiredtiger将會觸發checkpoint，如果在兩次checkpoint的時間間隔類evict淘汰線程淘汰的dirty page越少，那麼積壓的髒資料就會越多，也就是checkpoint的時候髒資料就會越多，造成checkpoint的時候大量的IO寫盤操作。如果我們把checkpoint的周期縮短，那麼兩個checkpoint期間的髒資料相應的也就會減少，磁盤IO 100%持續的時間也就會縮短。

  checkpoint調整後的值如下:

  checkpoint=(wait=25,log_size=1GB)

2.3.4 存儲引擎優化前後IO對比

  通過上面三個方面的存儲引擎優化後，磁盤IO開始平均到各個不同的時間點，iostat監控優化後的IO負載如下:

  從上面的io負載圖可以看出，之前的IO一會兒為0%，一會兒100%現象有所緩解，總結如下圖所示:

2.3.5 存儲引擎優化前後時延對比

  優化前後時延對比如下(注: 該叢集有幾個業務同時使用，優化前後時延對比如下):

  從上圖可以看出，存儲引擎優化後時間延遲進一步降低并趨于平穩，從平均80ms到平均20ms左右，但是還是不完美，有抖動。

3 伺服器系統磁盤IO問題解決

3.1 伺服器IO硬體問題背景

  如第3節所述，當wiredtiger大量淘汰資料後，發現隻要每秒磁盤寫入量超過500M/s，接下來的幾秒鐘内util就會持續100%，w/s幾乎跌0，于是開始懷疑磁盤硬體存在缺陷。

  從上圖可以看出磁盤為nvMe的ssd盤，檢視相關資料可以看出該盤IO性能很好，支援每秒2G寫入，iops能達到2.5W/S，而我們線上的盤隻能每秒寫入最多500M。

3.2 伺服器IO硬體問題解決後性能對比

  于是考慮把該分片叢集的主節點全部遷移到另一款伺服器，該伺服器也是ssd盤，io性能達到2G/s寫入(注意:隻遷移了主節點，從節點還是在之前的IO-500M/s的伺服器)。 遷移完成後，發現性能得到了進一步提升，時延遲降低到2-4ms/s，三個不同業務層面看到的時延監控如下圖所示：

  從上圖時延可以看出，遷移主節點到IO能力更好的機器後，時延進一步降低到平均2-4ms。

  雖然時延降低到了平均2-4ms，但是還是有很多幾十ms的尖刺，鑒于篇幅将在下一期分享大家原因，最終儲存所有時延控制在5ms以内，并消除幾十ms的尖刺。

  此外，nvme的ssd io瓶頸問題原因，經過和廠商确認分析，最終定位到是linux核心版本不比對引起，如果大家nvme ssd盤有同樣問題，記得更新linux版本到3.10.0-957.27.2.el7.x86_64版本，更新後nvme ssd的IO能力達到2G/s以上寫入。

4 總結及遺留問題

  通過mongodb服務層配置優化、存儲引擎優化、硬體IO提升三方面的優化後，該大流量寫入叢集的平均時延從之前的平均數百ms降低到了平均2-4ms，整體性能提升數十倍，效果明顯。

  但是，從4.2章節優化後的時延可以看出，叢集偶爾還是會有抖動，鑒于篇幅，下期會分享如果消除4.2章節中的時延抖動，最終保持時間完全延遲控制在2-4ms，并且無任何超過10ms的抖動，敬請期待，下篇會更加精彩。

  此外，在叢集優化過程中采了一些坑，下期會繼續分析大流量叢集采坑記。

  注意: 文章中的一些優化方法并不是一定适用于所有mongodb場景，請根據實際業務場景和硬體資源能力進行優化，而不是按部就班。