連結
TMO: Transparent Memory Offloading in Datacenters
- 通過 offload memory 實作空間擴充 + 空間 cost 的降低
- 同時不影響業務性能：其實很多篇幅是在講這個，但其本身不是目的，是技術手段
理念介紹
- Meta 的透明 (kernal-based) Memory offloading 技術：20% - 32% 記憶體收益 (13% from sidecar)
- 自動統計資源缺口計算回收量、同時控制匿名頁和檔案頁、支援 sidercar
對比
Googel g-swap 記憶體壓縮
- 不支援多多級：基于 SSD 比壓縮 cost 更低、整塊的資料無法壓縮
- 通過離線計算 per-workload 的壓縮比：經驗主義數值無法實時回報業務對于記憶體壓縮的敏感度
方案概述
- 可以 offload 多少
- 使用者程序根據 PSI 名額：Lost work due to resource shortage across CPU, memory, and I/O
- PSI 可以直接反映出 app 對于記憶體通路慢的敏感程度，而不是更低次元的系統名額
- 使用者程序 Senpai (前輩)，還挺有意思
- 哪些可以 offload
- 修改核心調整匿名頁和檔案頁的換入比例；per-container / per-sidercar 緯度計算
資料調研
Memory Offloading 落地的理論空間分析
- 不同代際的儲存設備；3 倍 compression；記憶體成本占計算架構總成本的比例 (成本怎麼算沒給出)
- 不同 app “冷”記憶體比例：per app in 1min、2min、5min、5min 以上沒 touch 的記憶體比例：總體空間是 35%
- Memory Tax：非業務記憶體的占比，totally 20%，TMO 首先落地的場景
- DataCenter：系統元件的記憶體
- MicroService：per-service 元件的記憶體，logging / mesh proxy ...
- 不同 app 的 匿名頁 和 檔案頁 的占比：TMO offloading 時需要考慮
- 不同代際的 SSD 裝置的性能名額
- TMO 現在支援 compressed memory && ssd；沒有支援 NVM / CXL
詳細設計
總體架構
- PSI 擷取到名額 (3)
- Senpai 通過 cgroup 接口控制 memory offloading 的實際、總量... (4)
- Memory Management export PSI 名額 + 觸發 offloading 行為 (5)、(6)
PSI 概述
- a measure of the impact on application performance due to lack of memory
- 正常基于 major fault 的方式不合理
- app 啟動時、working set 變化時、不同 (性能的) 儲存設備的 major fault 對 app 的影響也不同
名額含義
- considering only non-idle processes
- 程序分為 either runnable or stalled due to insufficient resources
- some： 至少有一個程序因為 resource 而 stall，刻畫程序級别的資源緊張
- full：所有程序都因為 resource 而 stall，刻畫整體的資源緊張
- main fallback = scheduling latency：在上下文切換時需要做些額外的事情
名額統計
基于各種 kernel level event 計算各資源次元的統計
- memory stall
- 記憶體滿了需要回收才能配置設定頁、需要等待 IO (eg. majos page fault)、swap in pages
- IO stall：any process waiting on block IO completion is stalled due to lack of IO
- CPU stall：a process is runnable but needs to wait for an idle CPU to become available
名額使用
- 很多 full pressure：系統程序或大頭業務程序異常，用作提前預警+需要及時處理，eg. 在 oom 前記憶體 fall
- some pressure：說明程序在某個資源次元敏感；最後将 some 維持在 high enough 但不産生業務幹擾的狀态
相反的，基于系統名額需要結合對底層硬體的了解才行
- io-read iops：磁盤算法對 IO Stall 有影響，隻通過 io read iops 不能看出 app 的性能影響
Senpai Operation
回收多少
high level 回收量的計算：some 越高 -> 記憶體越緊張 -> 越不應該觸發回收
- is the cgroup’s some PSI metric
- hh and re-claim_ratio are configurable parameters
- _ is the cur- rent memory footprint of the cgroup
計算值的下發
- Memory Stall
- 調整 memory limit：越大則 some 越小 (不緊張)
- 調整不及時則容易讓 some 變得很大 -> 不好用
- 新增 cgoruo interface = memory.reclaim
- This knob allows Senpai to ask the kernel to reclaim exactly the calculated memory amount
- 其他 Stall
- Senpai 也會基于 IO Stall 做操作，但是不會基于 CPU Stall
- 觸發回收時可能會引起 IO 的問題，但是不展現在 Memory latency 上
- 手段也是 memory，相當于簡介影響
- not found the CPU cycles spent on refaults to be significant
- 使用者态
- 使用者态還是比核心态好調節 (修改)
- 同時實時性不需要那麼強，甚至很多 batch 作業能夠忍受一定程度的 stall
線上環境(配置)：經驗值，非 auto tuning 得到
- _=0.0005 and _hh=0.1%
- re- claim is performed every six seconds：便于看到政策 (在一段時間内積累的) 效果
- 每次回收的 step：The maxi- mum is 1% of the total workload size in each reclaim period
回收誰
- 如何判斷 cold memory：即回收誰
- lRU for 匿名頁 && 檔案頁，額外的 cpu cycles 消耗 = 0.5% (很小)
- 更多将檔案頁刷回磁盤，少用 swap
- 基本想法是：很多檔案頁後面不會再用了 -> 但沒有量化名額去指導兩者的比例
- TMO 的思路是更好得平衡 頁刷磁盤 && swap out
- cache tracking
- 對于每個檔案維護 page fault count (全局遞增的)
- 檔案頁 A 被逐出時的 page fault count = x
- 檔案頁 A 下次被 fault-in 時，目前的 page fault count = y
- 如果 y-x < the size of resident memory (頁的數量) 則說明發生了 refault
- 用途
- 區分 re-fault 和 first-page fault：後者造成的 Memory Stall 不考慮
- 根據 refault-rate 和 page-in rate 調節 頁刷磁盤 && swap out 的比例
- 使用 zswap 能力：同樣 page fault 但是比磁盤更快
效果衡量
- 不同的 app 适合不同的 backend：主要是可壓縮的比例不同 (backend 二選一，不是層級的)
- Memory Tax rate：13%
- 業務性能：保證業務延遲的情況下，TMO 能有更多的 RPS，同時使用更少的記憶體空間
PSI vs Others
- RSS：不能反映對 app 的影響程度
- swap-in/sec：沒有考慮 swap 裝置的性能差異，也不能反映對 app 的影響
- 當使用 slower SDD 裝置時
- has lower RPS/performance but lower promotion/swap-in rate; while its PSI metrics are indeed higher
相關工作
- Remote Memory
- DRAM-NVM hybrid memories：需要 swap
- Cold page detection：基于 page table entry (PTE)