狠狠撸

吳奕慶
MongoDB Blockstore
記憶體及系統調教建議

摘要
? MongoDB Blockstore Memory 問題及分析過程說明
? 對於未來 Memory Alarm 條件的建議
? 頻繁備份作業的優化建議
? Swap Alarm 的觀察及優化建議
? 重點回顧及最終建議
2

Blockstore Memory 問題說明
? MongoDB 用來儲存備份資料的 Blockstore nodes 記憶體用量過高
? Alerting：Memory Available >= 95% (24GB x 95% = 22.8GB used) 是否合理?
? 是否需要先增加 VM 記憶體?
? 依系統特性評估是否需要增加記憶體，優先緩解問題?
? 增加多少記憶體要有依據也需要量化評估。
? 是否有機會減少 blockstore 本身記憶體的消耗量，又能平衡備份的穩定性?
? 記憶體真的不足的條件： alarm 條件是否需要再拿其他資訊來輔助說明?
? 最後手段再評估有沒有能讓 Linux kernel 更積極的回收記憶體參數?
? Linux kernel 參數調整是最後手段
3

是否需要先增加 VM 記憶體?
? Blockstore 發生問題時並不會馬上影響系統穩定度
? 目前 blockstore 雖然記憶體指標顯示吃緊，但系統依舊運作良好。
? 觀察 mongod 會自己回收 process 記憶體，但不是很積極。
? 總結:
? 暫不需要增加記憶體來緩解現在記憶體不足的 alarm
4

系統概況 -
Top Top -> g -> 3 可查看 process 的記憶體概況
5

減少 blockstore 記憶體的消耗量，
平衡備份的穩定性? (1) - 觀察
? 觀察 mongod 會增加及回收 process 的記憶體佔用，但不是很積極。
? 似乎有週期性增加或減少，但尚無法歸納 (也有可能被 OOM 而釋放記憶體，但目前沒 OOM log 蒐集)。
? 最多由 19.6Gb 降自 10.x GB
? 或許有 memory leak，但這屬於 mongod 的記憶體管理問題目前還沒進行排查。
? 使用 pmap 工具分析 mongod in process 的各類型記憶體的 address space 分布 :
? stack (kernel space)
? data / heap (user space) : 發現大部分分布於此，而在此處通常又被稱作 anonymous page
其可被回收但優先順序低
? 也就是說就算 process 沒有使用 anonymous page ，還是會被 process 佔住 (包含 memory leak)。
? anonymous cache 於系統非常吃緊時，Linux Kernel 才會啟動 ballooning 機制回收。
6

disk
disk
補充: Process address space
text space
(read only)
data space
Heap space
Stack space
(variable、function…)
0x000000
0x7fffff
Process
Linux Kernel / file system
disk
Read / write
Buffer /
Cache
Direct
access
Active
Inactive
Anonymous page
cat /proc/meminfo
free -h
User
process managed Linux kernel
managed
Mongod
Mongod
7
Mongod LRU
Linux Memory LRU
Linux kernel
ballooning

平衡備份的穩定性? (2) – 觀察
? 目前 point in time (PIT) 每秒平均 oplog 寫入量及 incremental backup 的資料
量非常小
? 證明 blockstore 預留的 wiretigerCacheSize 與 oplog 量相差懸殊
? 由上兩點可以說明，以現在的量來看，應該不需要讓 Mongod 在 process 內預
留太多記憶體給 wiretiger engine 而浪費記憶體。
8

MongoDB data / oplog 成長量統計
? 3/24 ~ 4/1 大約成長 < 6GB
9
per day per week
MongoDB Blockstore 儲存
的大部分是 Oplog

平衡備份的穩定性? (3) – 解決方案
? 是否可以限制 mongod process 的記憶體最大使用量?
? Memory cgroup
? 官方文件有提及 wiretigerCacheSize 也會影響記憶體使用量
? 不確定縮小 cache size 影響的是 Linux kernel 的 buff/cache 還是
anonymous page?
? 經 support 說明是縮小 anonymous page 大小
? 所以作用是將 memory 管理由 mongod 交給 Linux Kernel 利用 buff / cache
管理。
? buff / cache 相對於 anonymous page 會更優先被回收，而且人為更容易控
制。
10

Free (available) - 目前 Alarm 條件(1)
? 目前設定 Available >= 95% 為 Alarm 條件
? Available 值會受 watermark_low 影響
? 而未來如果我們想要 Linux kernel 更積極的幫我們回收 buff/cached
? 會調整 min_free_kbytes 的值
? 但 min_free_kbytes 也會影響到 watermark_low 的值 (後面 sar –B 說明)
? 另外 min_free_kbytes 的預設值也會因為實體記憶大小不同而不同
14

補充: Memory watermark
? /mm/page_alloc.c
15
隨 Linux kernel 版本的演進，watermark 值的計算及記憶體回收演算法也有改進，升級版本會有其必要性。
? Memory available 受 low watermark 影響
? Low watermark 又受 min_free_kbytes 影響
? 所以，memory available 受多種因素影響，因此，
單純只看這個值，不容易定義問題。

Free (available) - 目前 Alarm 條件(2)
? 結論，available 值會因為其他 Linux kernel 參數修改而改變
? 不能單純只設定一個百分比來當作 alert 條件。
? 因此，有設定 min_free_kbytes 時，alert 條件 available 的也需要跟著修改。
? 記憶體大小調整時，min_free_kbytes 也要修改。
16
min_free_kbytes 的預設值會因實體記憶大小而不同

補充: /proc/meminfo 檢視的目標
? MemTotal : OS 層可分配的實體記憶體 (VMware 給的記憶體大小)
? MemFree : 未被分配的實體記憶體。
? Buffers : 緩衝區記憶體 (Direct I/O) 直接讀寫 disk 的 block 產生
? Cached : 快取區記憶體 (經過 Linux FS 讀寫 disk 內的檔案內容)
? Inactive (file) : 在 Cached 內不常被使用的，將優先被 kernel 回收 (LRU)
? Active (file) : 被使用超過兩次以上的 Cached，次優先被回收。
? Active / Inactive (anon) : 屬於 process (Mongod) 內佔用的實體記憶體
? SReclaimable : 第一優先回收的 (slab)
? Free –h :
? buff/cache : Buffers + Cached + SReclaimable (slab)
17

補充: sar -r
? https://man7.org/linux/man-pages/man1/sar.1.html
? %memused：這個值是 kbmemused 和實體記憶體總量 (不包括 swap) 的百分比.
? kbbuffers 和 kbcached： /proc/meminfo - Buffers and Cached
? kbact: 目前系統常使用的 cached 大小，上圖顯示比例蠻大的。
? kbinact：此值是我們比較關切的，因為它是可以被優先回收的值。
? 結論:
? 這邊只能稍微瞭解記憶體的概觀
18

補充: sar –B (1) 記憶體回收原理
? Kswapd 是 Kernel Swap Daemon 的簡寫。
? 為什麼要觀察 kswapd? (記憶體不足時，首先 Linux 會先做記憶體回收，
而 kswapd 負責記憶體回收等作業。)
? pgscank/s: 每秒 kswapd 背景記憶體回收時所掃描的 page 數量
? pgscand/s: 每秒 kswapd 直接記憶體回收時所掃描的 page 數量
? pgsteal/s: 每秒回收的 page 數量
? kswapd 不是無時無刻在工作，其啟動條件由 /proc/zoneinfo 內的
(min/ low/ high) watermark 決定。
19

補充: sar –B (2) 記憶體回收原理
? min / low/ high 在 /proc/zoneinfo 可計算出
? kswapd 很忙，有可能是一直在做記憶體回收而造成 CPU high。
? Kswapd 也有可能忙著做 memory compaction
? pgscank 表示背景記憶體回收
? pgscand 直接記憶體回收，當下所有 process 會被 blocked
? Scan 次數有上限，達到後開始啟動 Swap 甚至觸發 OOM killer
? %vmeff 記憶體回收效率
? 如果 memory available 值很小，kswapd 又不忙，其實記憶體沒
那麼吃緊。(我們目前的狀況)
? 當 pgscank /pgscand 都不為零(kswapd 忙碌)，且 %vmeff 小於
如 50 %，表示難以回收記憶體，此時才真的表示記憶體吃緊。 20

小結 – 做了那些分析及觀察?
? 觀察 top 資源的分配用量
? Mongod 服務使用的資源是占大部分(70%)。
? 因此，我們深入研究 mongod 為什麼需要占用那麼多記憶體?
? 觀察 /proc/meminfo
? Buffers: 0 kB / Cached: 5766484 kB / SwapCached: 0 kB
? 深入了解 Cached 的指標含意，拆解 mongod 放甚麼在 filesystem 的 Cached?
? 深入了解 Mongod 的 Active/Inactive Anonymous page 為什麼占用那麼大?
? wiretigerCachesSize = (Memory -1GB) * 0.5
? 觀察 sar –B : kswapd 記憶體回收原理
? pgscank/s 及 pgscand/s 數值相當低且長時間為 0，available 值很低，其實當前負載量不大。
? 若長時間不為 0 且 %vmeff 不等於 100 則須關切，若 %vmeff< 50 顯示記憶體吃緊。
? 觀察 sar –r
? Kbact 是否比例過大，過大時需要再深入追蹤。
? kbinact 比例大時，表示大部分在記憶體的資料最近都沒有被重複讀取，應該調整 kernel 積極回收之。
21

小結 - 建議
? 原本想利用 memory cgroup 限制記憶體使用
? ( mongodb support - 不建議用在 mongod 服務上，見下一頁說明)
? wiredTigerCacheSize 的調整
? 目前 (24GB – 1GB) x 0.5 = 11.5GB
? 再搭配實際上 blockstore 的資料成長量來評估
? 現階段建議數值 5~6 GB，可應付未來 1 年的資料成長，並持續觀察 blockstore
運作狀況，隨時可調整。
? 調整後會改變 mongod 於記憶體類型中 data / Heap space 的佔用量。
? Mongod 會轉用 Linux 的 buffer / cached，所以之後交由 Linux kernel 接手做
會比較積極的做記憶體的回收。
? 讓現有的 alert 95% 可以調整低一點，也比較不會一直跳出告警。
? 最終還是要考慮多條件的設定，如 kswapd 運作狀態等等。
22

小結 - 驗證
? 目前已在 Staging MongoDB blockstore 設定： 1.5GB -> 1GB
? VM 記憶體容量: 4GB
? wiretigerCacheSize: 1.5GB -> 1GB
? Staging Oplog 量很小(與 prod 情境類似)
? 目前系統運作良好
? 研判 oplog 量不大時，wiretigerCacheSize 再大也是浪費。
23

(建議) 頻繁備份作業的優化建議–
Incremental Backup Period Change
? Incremental backup 也是增加記憶體使用量的原因之
一 (snapshot)
? 最初使用的 MongoDB 版本，因為 Point in Time (PIT)
功能有問題，而為了可能造成需要做 restore 的時間變
長，而拉長 MTTR 故障處理時間，所以做頻繁備份。
? 目前為每 6 小時/次，建議調整每日 (24小時) / 次
? 調整可利用 PIT recovery 的時間週期
? 由 1 天調整為 7 天或更小 (可考量 Storage 大小)
? Oplogs will be retained for this number of days.
? Snapshot must be kept more than this number of days.
24

建議 – swap alerting 的觀察及優化
? 我們目前有設定，當系統有使用 swap 時就跳出 Alarm。
? Swap 可以降低 process 被 OOM killed 的次數。
? Swap usage alarm:
? 系統有 Swap 不代表記憶體不足
? 如果調整了 vm.swappiness=100 不管當時記憶體是否足夠，系統都會積極的使用 swap，此時跳
alarm 似乎沒意義。
? 因此，若要在詳細看 swap 是否很頻繁，可以用 vmstat –w 或 sar -w 觀察 si / so
? swapin / swapout 長時間不為 0 並同時考慮 swappiness 值，能定義當頻繁 swap 時表示系統資源緊張。
? 此時再跳 alert 比較有意義，而不只看有沒有 swap。
? Swap 使用的儲存體，建議使用 SSD。
? Tmpfs 使用的儲存體，建議使用 SSD。
25

回顧及最終建議
? Alerting ：
? Memory Available >= 95% (24GB x 95% = 22.8GB used) 合理嗎?
? 經調整 wiretigerCacheSize 後，應可調回 75%。
? Alarm 條件可依上述建議調整，但需要將相關 log 集中才比較有機會設定多條件。
? 是否有機會減少 blockstore 本身記憶體的消耗量，又能平衡備份的穩定性?
? 除了瞭解 Linux metrics 外，Application (MongoDB) 的特性也需要瞭解，才有機會優化系統資源利用率。
? wiretigerCacheSize 調整 -> 5~6GB
? Incremental backup 頻率的調整 -> 24h / 次
? PIT recovery 週期改為 7 天
? 修改參數都不影響既有系統的運作，隨時可調整。
? 記憶體真的吃緊的條件:
? 重新思考，設定 available 使用率及 Swap已使用的 Alarm 之目的是甚麼?
? 記憶體吃緊?
? 不能只看 available 單一個值 (可增加 kswapd 的狀態)
? 需要多蒐集 sar log 的值
26

回顧及最終建議
? Swap alarm 若是用來當作記憶體吃緊的指標
? 建議改為觀察 vmstat –w 或 sar –w 的 swapin / swapout (si / so) 的指標長時間不為 0 時。
? 有沒有能讓 Linux kernel 更積極的回收記憶體
? 會在蒐集更多系統指標 log 後，觀察並分析必要性。
? Linux 本會盡量利用 Memory Buffer / Cached 來加快 I/O，但也會優先回收 Buffer / Cached。
? 應用系統本身也會善加利用 Linux 特性來提升效能。
? Buffer / Cached 回收當下不太會造成系統 Blocking。
? Windows Server 監控機制經驗與概念比對 Linux 上應該也要不同。
? 還要做 75% available 記憶體 Alarm 嗎?
27

狠狠撸

Mongodb Blockstore memory and system tuning

Recommended

More Related Content

What's hot (20)

Similar to Mongodb Blockstore memory and system tuning (20)

More from YI-CHING WU (6)

Mongodb Blockstore memory and system tuning

Editor's Notes