記憶體回收與壓縮（compaction）造成的暫停 Memory compaction / reclaim stalls (THP)

原因 ID so-reclaim · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）

OS 為了組出大分頁（huge page）而壓縮記憶體，或回收可用記憶體時，處理程序會停住。

為什麼 可用記憶體減少，或大分頁功能（THP）執行記憶體壓縮 → 於是要求記憶體的執行緒一直等到回收或壓縮結束 → 畫面上 不規則的伺服器暫停（數 ms～數百 ms）

症狀: 定格, 卡頓
因素: 停滯
誰會遇到: 整個伺服器
何時: 開越久越嚴重, 偶爾隨機發生
負責單位: 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 減少執行中的大型記憶體配置（啟動時預先配置並重複使用）。
基礎設施團隊要做的事: 將大分頁（THP）設為只在需要的地方使用（madvise），調高可用記憶體的門檻（vm.min_free_kbytes 等）。
圖表上: 偶爾隨機飆高 · 伺服器 tick 時間、記憶體 PSI
查看位置: 將 /proc/pressure/memory 的 some、full（為等待記憶體而停住的時間比例）與 /proc/vmstat 的 compact_stall 增加量和伺服器 tick 時間一起看，並確認 /sys/kernel/mm/transparent_hugepage/defrag 設定
符合的跡象: tick 飆高的時間點記憶體 PSI 上升、compact_stall 增加。defrag 為 always
不符合的跡象: PSI 與 compact_stall 沒有變化就不是這個原因。swap 用量增加時是「Swap」
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

Transparent Hugepage Support Linux kernel
defrag=always 時，THP 配置失敗會當場回收、壓縮記憶體而停住；madvise 則只有提出要求的區域會這樣做
Documentation for /proc/sys/vm/ Linux kernel
min_free_kbytes：kernel 要保留的最低可用記憶體（watermark）門檻
PSI - Pressure Stall Information Linux kernel
/proc/pressure/memory 的 some（部分工作為等待記憶體而停住的時間比例）、full（所有工作都停住的時間比例）