MONGODB大內存參數的調節以及checkpoint與性能的關系是怎樣的

這篇文章將為大家詳細講解有關MONGODB大內存參數的調節以及checkpoint與性能的關系是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

每種數據庫本身都有自身的特性,同時面臨的業務不同,也會導致每種數據庫需要進行調節,來滿足某種業務的需求.

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

這里重溫一下文檔的內容

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

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

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

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

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

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

這邊通過程序,對MONGODB 進行壓力測試,產生3000個連接,每個連接寫入200000 行數據.

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

那么我們會有幾個問題需要考慮,大量的數據寫入,我們有沒有時間將這些內存的數據在1分鐘內刷入到磁盤中,如果刷不完會怎樣.磁盤的壓力在此刻是不是會壓力山大. 那這個是不是算一個在某些MONGODB 數據庫中在承受大量寫時需要進行相關的調優需要考慮的事情.

其中重要的eviction_trigger  是保證當使用內存達到多少百分比,開始將內存的數據刷入到磁盤中, eviction_target 則是當內存的占比只要大于設置的值默認80% 就一直將數據刷入到磁盤中.

在高并發寫入,并且內存不足的情況下,主庫崩潰了,下面是相關的崩潰前的日志

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

所以這篇文字的目的就是要怎么在上面的情況下,調整參數,來優化一下當下的問題.

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

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

在調整完后,繼續3000個并發每個并發20萬的數據,可以從下圖對比文章中的第一個圖,可以看到 dirty  相對于第一張圖來比較,

所以對于大內存的MONGODB ,如果在高并發高寫入的情況下,適當的調整一下  eviction_trigger  和  eviction_target 可能對系統的性能會有提升.

另外上面的調整的參數需要根據自己的系統進行調整,不要按照文中的參數調整.

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