Mongodb Blockstore memory and system tuning

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

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

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

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

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

6. 減少 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

7. 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

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

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

10. 減少 blockstore 記憶體的消耗量，
平衡備份的穩定性? (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

11. 11

12. 12

13. 13
Memory Alarm 條件優化

14. 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

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

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

17. 補充: /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

18. 補充: 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

19. 補充: 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

20. 補充: 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

21. 小結 – 做了那些分析及觀察?
• 觀察 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

22. 小結 - 建議
• 原本想利用 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

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

24. (建議) 頻繁備份作業的優化建議–
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

25. 建議 – 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

26. 回顧及最終建議
• 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

27. 回顧及最終建議
• 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

28. Thank you
28