1、Alibaba Cloud Linux內核資源隔離及混部實踐背 景3其它類型的資源使用水位也很低混部的價值：提升資源利用率混部方案強依賴于內核各個子系統的資源隔離技術(based on Linux CGroup): CPU, 內存, I/O等。線上某業務容器的日常CPU水位：競 爭 根 因 定 位 工 具競 爭 指 標 數 據 大 盤健康度專家系統Alibaba Cloud Linux內核資源隔離 技術 Group IdentitySMT expellerIntel RDTmemcg 后臺 回收memcg 水線 分級用戶態oomd OOM優先級Cpuset & CpushareCFS 及時搶占

2、超線程干擾處理器LLC/MBMemory CGroupOOMMemory QoS CPU內存I/OAlibaba Cloud Linux 資源隔離技術方案網絡QoS打標頁緩存保護blkio bps throttleDirty throttleCGroup v1 writebackiolatency, iocost, ext4 jbd25CPUCpuset and CpushareCPU QuotaCGroup IdentifySMT expellerIntel RDT宿主機CPUcpuset容器cpuset容器超賣01903478111219251013Cpuset and Cpushare0

3、19調度權重1024*4 調度權重1024*4調度權重1024*4 調度權重1024*8 調度權重1024*4 調度權重1024*4技術對比優點缺點Cpuset部署簡單調度隔離性好Cache親和性好資源管理復雜，資源池機器資源碎片化加重規格粒度粗，資源利用率低動態擴容和動態縮容困難超賣后的長尾時延差CpushareCPU資源共享，資源利用率高可以提升有突發請求的業務性能超賣方案靈活，擴展性好容器調度粒度控制精細化應用并發度增加，容易失控調度爭搶加劇Cache污染Cpuset方式Cpushare方式宿主機CPUcpushare容器 cpushare容器cpushare容器 cpushare容器c

4、pushare容器超賣 cpushare容器超賣CGroup Identify以CPU CGroup組為單位實現調度特殊優先級，提升高優先級組的 及時搶占能力：基于Linux CFS調度器實現，代碼易維護懲罰低優先級組的vruntime增強高優先級組的搶占條件測試數據：使能本功能后，混部集群的電商業務RT(Response Time)可以 下降15%，基本恢復至非混部集群的水平。8SMT expellerCPU011分別同CPU1223互為SMT siblings左圖，在CPU1223上跑滿離線作業。右圖，接下來在CPU011上啟動在線作業，可以看到離線作業被抑制住。關于SMT超線程資源的干擾

5、，我們實測過某容器的QPS下降45%，RT增加60%。Intel RDT適用于RT時延比較敏感的業務場景:CAT, MBARDT只能靜態劃分資源，resctl接口。動態RDT需求，類似于Cpushare方式Intel新處理器的HWDRC(Hardware Dynamic Resource Controller)10內存memcg 后臺回收memcg 水線分級QoS: CGroup v1 memory.min and memory.low, unevictable processmemcg OOM 優先級user-space oomd based on PSImemcg 后臺回收內存慢速路徑上的

6、直接回收(direct reclaim)會嚴重 影響業務性能和RT(Response Time):global direct reclaim 和 memcg direct reclaim在memcg維度實現異步內存回收功能引入memcg的usage high 和 low水線類似kswapd內核線程的方式進行后臺異步回收缺點：異步回收的開銷不好歸屬至本memcgmemcg 水線分級 QoS保障異步全局kswapd停止 high水線異步全局kswapd激活 low水線離線內存申請同步限速觸發min水線默認min水線低優先作業的全局min水線上移 觸及水線后施加限速系統預留的緊 急保底內存區觸及此線

7、 才會影響 在線RT在離線安全 隔離水線高優先級的全局min水線下移系統預留的緊 急保底內存區觸及此線 才會影響 在線RT離線安全隔 離水線異步全局kswapd停止 high水線異步全局kswapd激活 low水線離線內存申請同步限速觸發min水線默認min水線 在線內存min水線下移混部水線參數調優后保障了大盤，但仍然存在著局部的隨機抖動需要解決。memcg 水線分級 功能效果綠線 為未部署任何方案時在線HSF RT變化曲線藍線 為整套memcg 水線分級方案下在線HSF RT變化曲線新接口memory.wmark_min_adj，范圍為-25, 50。配合較高的全局min水線（例如4GB8

8、GB)，通過vm.min_free_kbytes設置-25 means WMARK_MIN is WMARK_MIN + (WMARK_MIN - 0) * (-25%)”50 means WMARK_MIN is WMARK_MIN + (WMARK_LOW - WMARK_MIN) * 50%”負值代表min水線下移，代表的是對內存QoS要求高的memcg組(例如在線組)。正值代表min水線上移，代表的是對內存QoS要求低的memcg組(例如離線組)。紅線 為無任何內存壓力的在線HSF RT曲線，平穩在150附近綠線 為全局大內存壓力下的未部署方案時在線HSF RT曲線，產生了較大波動藍線

9、 為水線等優化手段后的在線HSF RT曲線，依然有大波動memcg OOM優先級k8s利用oom_score_adj設計Guaranteed/Burstable/Best-Effort不同類型OOM優先級方案:/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md內核態設計OOM優先級，支持Global OOM和CGroup OOM，相比k8s更靈活高效。新接口memory.priority，范圍0, 12，數值越大優先級越高。優先級的生效范圍為同級memcg之間。root/CDE

10、FAB/memory.priority:A:10B:8C:5D:6E:7F:8當發生Global OOM時，從根組(root)開始按每個層級數據最小的原則遍歷路徑 root-B-E，最終E被選出來作為被殺對象。oomd基 于 Memory CGroup PSI 在 用 戶 態 實 現 oom killer: /2018/07/19/production-engineering/oomd/關鍵難點：PSI數據的準確性和及時性Bad case的安全兜底，試想一下極端并發匿名頁申請導致瞬間OOM(一秒以內)16IO主要為了解決共享盤/ext4文件系統的場景CGroup v1 writeback: b

11、uffered writes blkio throttleCGroup v1 dirty throttle高版本移植 iolatency, iocostDisk quota (容器下的root權限的disk quota hardlimit受限)ext4 jbd2 調優CGroup v1 writebackBlkio-throttle用來解決共享磁盤帶寬的場景，但buffered寫是由kthread后臺周期性提交IO落盤,標準CGroup v1無法獲得blkio的限流配置?；赾group v1接口，實現per-cgroup的writeback將memcg和blkcg兩CGroup信息橋接起來，

12、inode bdi記錄memcg和blkcg信息，這樣就可 以在kthread上下文獲取相應的blkcg限流配置實現異步寫per-blkio的buffered IO throttle接口：blkio.throttle.write_bps_device, blkio.throttle.write_iops_device配置示例echo 8:32 104857600 /sys/fs/cgroup/blkio/test/blkio.throttle.write_bps_device echo 10080 /sys/fs/cgroup/blkio/test/tasksecho 10080 /sys/f

13、s/cgroup/memory/test/tasks其中，8:32為設備的主次設備號，104857600為bps即100MiB/s，10080為業務進程pid。 注：需要將業務進程同時配置到對應的memcg和blkcg中。CGroup v1 dirty throttle有了CGroup v1 wirteback之后，就可以進一步在更高層(VFS)實現per-memcg dirty throttle， 極大地緩解共享文件系統(以及blkio-throttle)導致的“IO優先級反轉”難題:memory.dirty_bytesratio，類似于vm.dirty_bytesratiomemory.d

14、irty_background_bytesratio ，類似于vm.dirty_background_bytesratio主要邏輯實現位于balance_dirty_pages()ext4 jbd2 調優調小 nr_requestsremount參數: lazytime, nobarrier等異步checkpointUpstream ext4 jbd2 fast commit: /Articles/834483/20容器資源視圖隔離top, free, ps, uptime 容器視圖:/proc/cpuinfo/proc/stat/proc/stat/proc/loadavg/proc/upt

15、ime/proc/meminfo/sys/devices/system/cpu/online- 相比用戶態lxcfs方案，實現傻瓜式開箱即用，定制化高級指標。21容器資源視圖隔離 示例某個部署在物理服務器上的4c8g規格容器:如果沒有容器資源視圖，看到的將是宿主機的100-CPU的top數據22標準化SLI Global and CGroupGeneralCPUMemoryIO/FSNetworkper_cgroup /proc/stat per_cgroup load.d/load.rsoftlockup, hung task, rcu stall (proc方式)整機sys(識別有害sys

16、)CGroup數目監控 微架構PMU資源競爭(IPC, LLC, 內存帶寬)PSI cpu pressurePSI memory pressurePSI io pressureRX/TX bps/ppsqueue other/queue siblingdirect reclaim/compaction/swapdisk avgqu-sz/await/utilTCP retrans ratehistogramsper-cgroup stealdisk io hungworkingset refault/activate/restoreCPU Quota throttleext4 jbd2 tra

17、nsactionswriteback/dirty(/proc/fs/jbd2/stats)wait/block/ioblock histogramsSlab/Sreclaimable/SUnreclaimblkio iops/bps/throttleGlobal/CGroup OOMmemory leak detectionkswapdNUMA infoSLI 示例 常見監控抖動load.r抖動內存帶寬緩存顛簸內存分配時延24SLI 示例 PSI標準指標注：針對CPU健康度指標，除了調度時延外，還加入了 調度阻塞的數據聚合25標準化SLI的數據化價值數據的價值是無限的量化出SLO分析當前集群的

18、問題癥結: CPU, Memory, I/O等集群聚合數據分析，業務資源Profiling，大盤告警等數據驅動集群調度(k8s)決策: 流量調度，驅逐策略，資源調優5. .26混部集群穩定性 隨機抖動難題異常表現LOAD 高SYS 高iowait/disk await 高TCP重傳高Memory CGroup 綜合癥(cgroup_mutex大鎖，memory.stat時延，memcg kmem問題，memcg殘留等)因素太多CFS算法時延，內核關搶占，全局鎖競爭(spinlock, mutex, semaphore)，中斷、軟中斷，關中斷，調度阻 塞，調度抑制，內存回收，內存碎片，大內存釋放，ext4/jbd2 wait transaction, io hung等。27輕量級資源消耗, 不影響性能，能夠穩定常態化部署設定指標異常門限，抓取異?，F場CallTracein-kernel blackbox triggers, ali-diagnose等工具工具定位根因28深水區混部=50%的整機CPU水位資源超賣CPU資源超賣(相對容易)內存資源超賣不要高估NVMe盤性能(隨機寫更慢，200MiB)，不要低估共享文件系統的挑戰：“做IO分盤(獨立云盤) ”網絡QoS，獨立的虛擬網卡安全兜底方案，能夠及時處理“bad case”用戶無感29內存資