MONGODB大內(nèi)存參數(shù)的調(diào)節(jié)以及checkpoint與性能的關(guān)系是怎樣的

這篇文章將為大家詳細(xì)講解有關(guān)MONGODB大內(nèi)存參數(shù)的調(diào)節(jié)以及checkpoint與性能的關(guān)系是怎樣的，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

每種數(shù)據(jù)庫本身都有自身的特性,同時面臨的業(yè)務(wù)不同,也會導(dǎo)致每種數(shù)據(jù)庫需要進(jìn)行調(diào)節(jié),來滿足某種業(yè)務(wù)的需求.

大部分場景下,對于MONGODB的配置上都比較粗暴,這當(dāng)然是相對于 PG, MYSQL 而言的,各種細(xì)微的調(diào)整,對于某些參數(shù)的琢磨. 那么實際上MONGODB 本身的參數(shù)也并不是不需要琢磨,他就能適應(yīng)各種情況, 量變到質(zhì)變的道理大家都懂.

這里重溫一下文檔的內(nèi)容

1 在MONGODB 3.4 默認(rèn)使用 50%的內(nèi)存在數(shù)據(jù)庫中有1G 內(nèi)存及以上的情況,而如果在不足1G 內(nèi)存的情況下使用 256MB的方式為MONGODB 提供內(nèi)存服務(wù). 

問題,為什么是50% , 而不是和MYSQL 一樣的60% - 80%,也就是說越大越好,這里如果使用過POSTGRESQL 則可能會理解MONGODB 的為什么要50%而不是更大,因為他們都要基于LINUX 的緩沖機(jī)制來進(jìn)行相關(guān)的數(shù)據(jù)處理工作.

PG就不在贅述,而MONGODB 主要使用LINUX的緩沖技術(shù)的主要原因是數(shù)據(jù)壓縮,使用過MONGODB的人都知道MONGODB對數(shù)據(jù)壓縮后和實際數(shù)據(jù)的大小之間的比率還是比較大的,這樣會節(jié)省數(shù)據(jù)的存儲空間和以及相關(guān)的處理數(shù)據(jù)的成本.

但任何數(shù)據(jù)在進(jìn)行處理之前都需要解壓縮,而解壓縮如果是從磁盤到內(nèi)存則速度和相關(guān)的性能消耗都不會太低,則MONGODB選擇了LINUX 的緩沖cache作為解壓縮和壓縮的一個環(huán)境. 

問題1  MONGODB 到底多長時間checkpoint一次,下面做一個 test 來回答這個問題

從圖中就可以很明確的看到這個問題,時間是1分鐘,1分鐘進(jìn)行一次checkpoint 的操作.

這邊通過程序,對MONGODB 進(jìn)行壓力測試,產(chǎn)生3000個連接,每個連接寫入200000 行數(shù)據(jù).

這里就會產(chǎn)生一個矛盾,如果我內(nèi)存大,例如512G ,并且使用一半的內(nèi)存256G,然后進(jìn)行臟頁的刷新,每隔60秒將數(shù)據(jù)刷入到磁盤. 

那么我們會有幾個問題需要考慮,大量的數(shù)據(jù)寫入,我們有沒有時間將這些內(nèi)存的數(shù)據(jù)在1分鐘內(nèi)刷入到磁盤中,如果刷不完會怎樣.磁盤的壓力在此刻是不是會壓力山大. 那這個是不是算一個在某些MONGODB 數(shù)據(jù)庫中在承受大量寫時需要進(jìn)行相關(guān)的調(diào)優(yōu)需要考慮的事情.

其中重要的eviction_trigger  是保證當(dāng)使用內(nèi)存達(dá)到多少百分比,開始將內(nèi)存的數(shù)據(jù)刷入到磁盤中, eviction_target 則是當(dāng)內(nèi)存的占比只要大于設(shè)置的值默認(rèn)80% 就一直將數(shù)據(jù)刷入到磁盤中.

在高并發(fā)寫入,并且內(nèi)存不足的情況下,主庫崩潰了,下面是相關(guān)的崩潰前的日志

那可以試想如果你擁有了大內(nèi)存,還使用默認(rèn)的參數(shù),并且還持續(xù)大量的寫入,你的磁盤性能 還是一般般的水平, 呵呵.

所以這篇文字的目的就是要怎么在上面的情況下,調(diào)整參數(shù),來優(yōu)化一下當(dāng)下的問題.

當(dāng)然如果你的磁盤是SSD 并且寫入數(shù)量不大,當(dāng)然可以忽略這里所探討的一切.

db.adminCommand( { "setParameter": 1, "wiredTigerEngineRuntimeConfig": "eviction=(threads_min=3,threads_max=6),checkpoint=(wait=120),eviction_trigger=80,eviction_target=50"})

在調(diào)整完后,繼續(xù)3000個并發(fā)每個并發(fā)20萬的數(shù)據(jù),可以從下圖對比文章中的第一個圖,可以看到 dirty  相對于第一張圖來比較,

所以對于大內(nèi)存的MONGODB ,如果在高并發(fā)高寫入的情況下,適當(dāng)?shù)恼{(diào)整一下  eviction_trigger  和  eviction_target 可能對系統(tǒng)的性能會有提升.

另外上面的調(diào)整的參數(shù)需要根據(jù)自己的系統(tǒng)進(jìn)行調(diào)整,不要按照文中的參數(shù)調(diào)整.

關(guān)于MONGODB大內(nèi)存參數(shù)的調(diào)節(jié)以及checkpoint與性能的關(guān)系是怎樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。