記憶體碎片化 Heap fragmentation

原因 ID mem-fragment · 主要負責 遊戲開發團隊（伺服器開發）

反覆配置與釋放，讓閒置空間被切得零碎時，占用的記憶體會遠多於實際使用量。

為什麼 多個執行緒長時間配置、釋放大小不一的記憶體 → 於是閒置空間零散分布，無法歸還給 OS，用量像洩漏一樣持續增加 → 畫面上 開越久越會因 swap 與記憶體不足而變慢，最後被強制終止

症狀: 慢動作, 斷線
因素: 停滯
誰會遇到: 整個伺服器
何時: 開越久越嚴重
負責單位: 主要負責 遊戲開發團隊（伺服器開發）
遊戲開發團隊要做的事: 依大小分類的記憶體池、不易碎片化的記憶體配置器（jemalloc、mimalloc 等）。
圖表上: 緩慢爬升 · 處理程序記憶體（RSS）
查看位置: 用同一個 build 啟動兩台伺服器，只在其中一台以環境變數 MALLOC_ARENA_MAX 減少 glibc arena 數量，或換成 jemalloc 等其他配置器，比較數天內 pidstat -r 的 RSS
符合的跡象: 人數與物件數相近，只有調整過的伺服器 RSS 停止增加或增幅大減
不符合的跡象: 換了配置器仍同樣上升時，是沒有釋放的記憶體（mem-leak）
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）
深入了解: 表現和洩漏一模一樣，但分析 heap 找不到洩漏點。Linux 的預設配置器（glibc）在執行緒多的伺服器上特別嚴重，有時光是換掉配置器，用量就會大幅下降。

出處

mallopt(3) — Linux manual page Linux man-pages
glibc malloc 為了減少執行緒競爭，會建立多達 CPU 數倍數的 arena，arena 越多記憶體用量越大（以 M_ARENA_MAX 限制，也可用環境變數 MALLOC_ARENA_MAX 設定）
jemalloc memory allocator jemalloc
重視避免碎片化與並行擴展性的通用 malloc 實作
pidstat(1) — Linux manual page sysstat
-r：各處理程序的 RSS（實際位於 RAM 中的記憶體）