10年的阜新網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整阜新建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“阜新網(wǎng)站設(shè)計(jì)”,“阜新網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

MongoDB lsm降低 disk lantency

背景

Part1:寫在最前

在副本集架構(gòu)中，當(dāng)我們面臨寫多讀少，且大多數(shù)寫為update操作時(shí)，WT引擎的瓶頸初顯。這直接導(dǎo)致業(yè)務(wù)反饋寫入操作耗時(shí)較久等異常。為此，Percona版本的MongoDB里支持rocksDB存儲(chǔ)引擎，應(yīng)對(duì)寫比較多的時(shí)候會(huì)顯得更加從容。

Part2:背景

在業(yè)務(wù)大量更新的場(chǎng)景中我們發(fā)現(xiàn)WT存儲(chǔ)引擎的disk lantency會(huì)比較高，在嘗試調(diào)大cache_size和并發(fā)數(shù)、eviction后效果不佳，因此我們嘗試使用rocksDB引擎代替。

Part3:措施

將write concern從majority變更為1，觀察效果

w: 數(shù)據(jù)寫入到number個(gè)節(jié)點(diǎn)才向用客戶端確認(rèn){w: 0} 對(duì)客戶端的寫入不需要發(fā)送任何確認(rèn)，適用于性能要求高，但不關(guān)注正確性的場(chǎng)景

{w: 1} 默認(rèn)的writeConcern，數(shù)據(jù)寫入到Primary就向客戶端發(fā)送確認(rèn)

{w: “majority”} 數(shù)據(jù)寫入到副本集大多數(shù)成員后向客戶端發(fā)送確認(rèn)，適用于對(duì)數(shù)據(jù)安全性要求比較高的場(chǎng)景，該選項(xiàng)會(huì)降低寫入性能

j: 寫入操作的journal持久化后才向客戶端確認(rèn)默認(rèn)為”{j: false}，如果要求Primary寫入持久化了才向客戶端確認(rèn)，則指定該選項(xiàng)為true

 

之前開了majority，慢的同時(shí)，在3.2.6版本后，也會(huì)同時(shí)開啟journal日志的磁盤寫入，導(dǎo)致磁盤耗時(shí)增加，進(jìn)而導(dǎo)致寫入更慢，把writeconcern改到1，可以提升寫入速率

相關(guān)參數(shù)

writeConcernMajorityJournalDefault

Part4:日志抓取

2018-08-21T01:00:50.096+0800 I COMMAND  [conn4072412] command kgcxxxt.$cmd command: update { update: "col", ordered: true, writeConcern: { w: "majority" }, $db: "kgcxxxt" } numYields:0 reslen:295 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 1 } }, oplog: { acquireCount: { w: 1 } } } protocol:op_query 137ms

....

....

2018-08-21T01:00:50.096+0800 I COMMAND  [conn4072176] command kgcxxxt.$cmd command: update { update: "col", ordered: true, writeConcern: { w: "majority" }, $db: "kgcxxxt" } numYields:0 reslen:295 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 1 } }, oplog: { acquireCount: { w: 1 } } } protocol:op_query 137ms

Part5:監(jiān)控

替換為write concern 1后，qps提高到15k

Part6:調(diào)大相關(guān)參數(shù)

嘗試調(diào)大cache_size和eviction
db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "cache_size=90G"})
 
db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "eviction=(threads_min=1,threads_max=8)"})

可以看出，在調(diào)大參數(shù)后排隊(duì)的情況降下來(lái)了

但是這一好景不長(zhǎng)，沒過(guò)多久依舊出現(xiàn)了我們不希望看到的情況，因此后續(xù)我們決定采用rocksDB引擎。

實(shí)戰(zhàn)

Part1:整體架構(gòu)

原有集群為3節(jié)點(diǎn)副本集架構(gòu)，均使用WT存儲(chǔ)引擎。我們將其中一臺(tái)從庫(kù)換為rocksDB存儲(chǔ)引擎，觀察disk lantancy情況。

如上圖所示，可以看出主節(jié)點(diǎn)的QPS情況。

Part2:rocksDB引擎從庫(kù)

我們將其中一臺(tái)從庫(kù)配置為rocksDB引擎，RocksDB相對(duì)WT一大改進(jìn)是采用LSM樹存儲(chǔ)引擎。Wiredtiger 基于 btree 結(jié)構(gòu)組織數(shù)據(jù)，在一些極端場(chǎng)景下，因?yàn)?Cache eviction 及寫入放大的問(wèn)題，可能導(dǎo)致 Write hang，細(xì)節(jié)可以到 MongoDB jira 上了解相關(guān)的issue，針對(duì)這些問(wèn)題 MongoDB 官方團(tuán)隊(duì)一直在優(yōu)化，我們也看到 Wiredtiger 穩(wěn)定性在不斷提升；而 RocksDB 是基于 LSM tree 結(jié)構(gòu)組織數(shù)據(jù)，其針對(duì)寫入做了優(yōu)化，將隨機(jī)寫入轉(zhuǎn)換成了順序?qū)懭耄鼙ＷC持續(xù)高效的數(shù)據(jù)寫入。在替換其中一臺(tái)從庫(kù)為rocksDB引擎后，我們將其與另外一臺(tái)WT引擎的從庫(kù)進(jìn)行disk lantency的對(duì)比。

下圖為使用lsm Tree 結(jié)構(gòu)的rocksDB存儲(chǔ)引擎從庫(kù)的disk lantency，可以看出都在1ms內(nèi)。

其qps如下圖所示，repl_delete在3k左右且連續(xù)穩(wěn)定。

Part3:WT引擎從庫(kù)

下圖為使用WT存儲(chǔ)引擎從庫(kù)，其disk lantency和主庫(kù)一樣，寫入的lantency達(dá)到了8ms，讀也有4ms

其qps在2.3k左右，且監(jiān)控出現(xiàn)斷點(diǎn)，從庫(kù)出現(xiàn)因壓力大登錄超時(shí)的情況。

Part4:RocksDB引擎配置參數(shù)

storage:
  engine: rocksdb
  useDeprecatedMongoRocks: true
  dbPath: /home/work/mongodb/mongo_28000/data/db_28000
  indexBuildRetry: true
  journal:
    enabled: true
    commitIntervalMs: 100
  rocksdb:
    cacheSizeGB: 10
    compression: snappy
    maxWriteMBPerSec: 1024
    configString: write_buffer_size=512M;level0_slowdown_writes_trigger=12;min_write_buffer_number_to_merge=2;
    crashSafeCounters: false
    counters: true
    singleDeleteIndex: false

注釋1

#storage Options
storage:
  engine: "rocksdb"
  useDeprecatedMongoRocks: true   ##percona 3.6版本需要加
  dbPath: /home/work/mongodb/mongo_10001/data
  rocksdb:
    cacheSizeGB: 10  # 默認(rèn)是30% of physical memory
    compression: snappy
    maxWriteMBPerSec: 1024 #單位MB，rocks writes to storage 的速度，降低這個(gè)值可以減少讀延遲刺尖，但該值太低會(huì)降低寫入速度
    configString: write_buffer_size=512M;level0_slowdown_writes_trigger=12;min_write_buffer_number_to_merge=2;   
   crashSafeCounters: false  #指定crash之后是否正確計(jì)數(shù)，開啟這個(gè)選項(xiàng)可能影響性能
    counters: true   #（默認(rèn)開）指定是否使用advanced counters，關(guān)閉它可以提高寫性能
    singleDeleteIndex: false

在添加 configString: write_buffer_size=512M;level0_slowdown_writes_trigger=12;min_write_buffer_number_to_merge=2;   參數(shù)后，磁盤延遲進(jìn)一步降低，iops也進(jìn)一步降低

這里需要注意的是，percona從3.6版本起不建議使用rocksdb，可能在下一個(gè)大版本移除，至于是否選用，要根據(jù)實(shí)際情況出發(fā)，最好能夠拉上業(yè)務(wù)一起進(jìn)行一個(gè)壓測(cè)，滿足業(yè)務(wù)需求的，就是最好的。

https://www.percona.com/doc/percona-server-for-mongodb/LATEST/mongorocks.html

注釋2

rocksdb參數(shù)的調(diào)節(jié)一般是在三個(gè)因素之間做平衡：寫放大、讀放大、空間放大
1.flush選項(xiàng)：
write_buffer_size:
memtable的最大size，如果超過(guò)了這個(gè)值，RocksDB就會(huì)將其變成immutablememtable，并在使用另一個(gè)新的memtable
max_write_buffer_number:
最大memtable的個(gè)數(shù)，如果activememtablefull了，并且activememtable加上immutablememtable的個(gè)數(shù)已經(jīng)到了這個(gè)閥值，RocksDB就會(huì)停止后續(xù)的寫入。通常這都是寫入太快但是flush不及時(shí)造成的。
min_write_buffer_number_to_merge:
在flush到level0之前，最少需要被merge的memtable個(gè)數(shù)。如果這個(gè)值是2，那么當(dāng)至少有兩個(gè)immutable的memtable的時(shí)候，RocksDB會(huì)將這兩個(gè)immutablememtable先merge，再flush到level0。預(yù)先merge能減小需要寫入的key的數(shù)據(jù)，譬如一個(gè)key在不同的memtable里面都有修改，那么我們可以merge成一次修改。但這個(gè)值太大了會(huì)影響讀取性能，因?yàn)镚et會(huì)遍歷所有的memtable來(lái)看這個(gè)key是否存在。
舉例：write_buffer_size=512MB;max_write_buffer_number=5;min_write_buffer_number_to_merge=2;
假設(shè)寫入速率是16MB/s，那么每32s的時(shí)間都會(huì)有一個(gè)新的memtable生成，每64s的時(shí)間就會(huì)有兩個(gè)memtable開始merge。取決于實(shí)際的數(shù)據(jù)，需要flush到level0的大小可能在512MB和1024MB之間，一次flush也可能需要幾秒的時(shí)間
（取決于盤的順序?qū)懭胨俣龋Ｗ疃嘤?個(gè)memtable，當(dāng)達(dá)到這個(gè)閥值，RocksDB就會(huì)組織后續(xù)的寫入了。

2.LevelStyleCompaction：
level0_slowdown_writes_trigger:
當(dāng)level0的文件數(shù)據(jù)達(dá)到這個(gè)值的時(shí)候，就開始進(jìn)行l(wèi)evel0到level1的compaction。所以通常level0的大小就是write_buffer_size*min_write_buffer_number_to_merge*level0_file_num_compaction_trigger。
max_background_compactions:
是指后臺(tái)壓縮的最大并發(fā)線程數(shù)，默認(rèn)為1，但為了充分利用你的CPU和存儲(chǔ)，可以將該值配置為機(jī)器核數(shù)
max_background_flushes:
并發(fā)執(zhí)行flush操作的最大線程數(shù)，通常設(shè)置為1已經(jīng)是足夠了。

如下是使用 sysbench 進(jìn)行的一個(gè)簡(jiǎn)單的 insert 測(cè)試，insert 的集合默認(rèn)帶一個(gè)二級(jí)索引，在剛開始 Wiredtiger 的寫入性能遠(yuǎn)超 RocksDB，而隨著數(shù)據(jù)量越來(lái)越大，WT的寫入能力開始下降，而 RocksDB 的寫入一直比較穩(wěn)定。

更多 Wiredtiger、Mongorocks 的對(duì)比可以參考 Facebook 大神在 Percona Live 上的技術(shù)分享。

https://www.percona.com/live/17/sessions/comparing-mongorocks-wiredtiger-and-mmapv1-performance-and-efficiency?spm=a2c4e.11153940.blogcont231377.21.6c457b684BOXvj

——總結(jié)——

通過(guò)本文，我們了解到RocksDB引擎的特點(diǎn)和與WT存儲(chǔ)引擎的disk lantency對(duì)比，不同的業(yè)務(wù)場(chǎng)景不同，因此具體使用什么存儲(chǔ)引擎，還需要結(jié)合具體業(yè)務(wù)來(lái)進(jìn)行評(píng)估。由于筆者的水平有限，編寫時(shí)間也很倉(cāng)促，文中難免會(huì)出現(xiàn)一些錯(cuò)誤或者不準(zhǔn)確的地方，不妥之處懇請(qǐng)讀者批評(píng)指正。喜歡筆者的文章，右上角點(diǎn)一波關(guān)注，謝謝~

參考資料：

https://www.percona.com/doc/percona-server-for-mongodb/LATEST/mongorocks.html

https://yq.aliyun.com/articles/231377

https://www.percona.com/live/17/sessions/comparing-mongorocks-wiredtiger-and-mmapv1-performance-and-efficiency?spm=a2c4e.11153940.blogcont231377.21.6c457b684BOXvj

彩蛋

歷經(jīng)1年時(shí)間，和我的摯友張甦先生合著了這本《MongoDB運(yùn)維實(shí)戰(zhàn)》，感謝電子工業(yè)出版社，感謝張甦先生讓我圓了出書夢(mèng)！感謝友東哥、李丹哥、李彬哥、張良哥的書評(píng)！感謝友飛哥、汝林哥在我入職小米以來(lái)工作上的指導(dǎo)和幫助！感謝我的愛人李愛璇女士，沒有你在背后支持，我不可能完成這項(xiàng)龐大的工程。京東自營(yíng)有貨，喜歡MongoDB的同學(xué)歡迎支持！

網(wǎng)站標(biāo)題：MongoDBlsm降低disklantency
網(wǎng)頁(yè)鏈接：http://www.chinadenli.net/article2/jdhpic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、網(wǎng)站策劃、移動(dòng)網(wǎng)站建設(shè)、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)