背景
在雲原生場景中，為了最大化資源利用率，越來越多的集羣採用資源超賣策略和混合部署方式。然而，這種模式在提升集羣效率的同時，也顯著增加了宿主機與容器化應用之間的資源競爭風險。
在資源緊張的場景中，CPU 延時和內存申請延遲（Memory Reclaim Latency）等內核級延遲問題，往往會直接傳導至應用層，造成響應時間（RT）波動，甚至引發業務抖動。對於依賴低延遲和穩定性的關鍵業務而言，這類問題可能意味着性能瓶頸、用户體驗下降，甚至業務中斷。
然而，現實中由於缺乏足夠的可觀測性數據，工程師通常很難將應用層抖動與系統層面的延遲精確關聯，排查效率低下。為了解決這一挑戰，本文將結合實戰案例，介紹如何在 Kubernetes 環境中使用 ack-sysom-monitor Exporter [1]對內核延遲進行可視化分析與定位，幫助你快速識別問題根因，並高效緩解由延遲引發的業務抖動。
內存申請延時
進程陷入內存分配的慢速路徑往往是造成業務時延抖動的元兇之一。如下圖所示，在進程內存分配的過程中，如果系統或容器內存達到了low 水線，會觸發系統內存的異步回收（kswapd 內核線程回收）；如果剩餘內存進一步低於 min 水線，就會進入直接內存回收（direct reclaim）和直接內存規整（direct compact）階段，這兩個動作正是可能引起長業務（進程）時間延時的罪魁禍首。
- 直接內存回收是指進程在申請內存的過程中，由於內存緊缺，進程被迫阻塞等待內存的同步回收。
- 直接內存規整是指進程在申請內存的過程中，由於內存碎片太多，進程被迫阻塞等待內核將內存碎片規整成連續可用的一片內存。
因為直接內存回收和規整的過程可能會消耗一定的時間，所以進程會阻塞在內核態，造成長時間的延時和 CPU 利用率的升高，從而導致系統負載飆高和（業務）進程的延時抖動。
圖： Linux內存水線
CPU 延時
CPU 延時是指從任務變為可運行狀態（即它已準備好運行，不再受阻塞），到它真正被操作系統調度器選中並執行的時間間隔。長時間的 CPU 延時可能會對業務造成影響，如網絡數據包到達後，業務進程沒有被及時調度運行進行收包從而導致網絡延時等。
延時抖動場景常見 case
CASE1: 容器內存緊張導致容器內應用抖動
容器啓動時設置了內存限制（Limit）。當容器內進程申請內存且容器內存使用量達到容器內存限制時，容器內進程就會發生直接內存回收和規整導致應用阻塞。
CASE2: 宿主機內存緊張導致容器內應用抖動
雖然容器內存富餘，但容器所在宿主機內存緊張。當容器內進程申請內存且節點內存可用內存低於節點 min 內存水位時，容器內進程就會發生直接內存回收。
CASE3: 就緒隊列等待時間長導致應用抖動
應用進程被喚醒進入就緒隊列，但是由於就緒隊列較長，當前 CPU 存在阻塞任務等原因導致長時間沒有被調度至 CPU 運行導致應用抖動。
CASE4：中斷，阻塞時間長導致應用抖動
當系統資源緊張或發生資源爭搶時，大量網絡等軟件中斷或硬件中斷會持續觸發。此時內核處理這些中斷的耗時會顯著增加，導致 CPU 長時間被內核佔用。應用程序在運行系統任務時需要爭奪同一個鎖，但此時鎖資源長期被佔用無法釋放，最終引發進程卡死。
CASE5：內核路徑持鎖阻塞引發網絡抖動延時
當進程通過系統調用進入內核態執行路徑後，由於路徑中可能涉及訪問大量系統資源從而長時間持有內核自旋鎖；當某個 CPU 在持有自旋鎖後便可能關閉當 CPU 中斷和不再發生調度，從而導致內核 ksoftirq 軟中斷無法正常調度收包，從而引發網絡抖動。
如何識別解決系統抖動延時
ACK 團隊與操作系統團隊合作推出了 SysOM（System Observer Monitoring） 操作系統內核層的容器監控的產品功能，目前為阿里雲獨有；通過查看 SysOM 容器系統監控 -None 和 Pod 維度中的相關大盤，可以洞悉節點和容器的抖動延時。
內存申請延時
- 查看 SysOM 容器系統監控-容器維度中的Pod Memory Monitor 中的Memory Global Direct Reclaim Latency和Memory Direct Reclaim Latency 和 Memory Compact Latency 監控大盤，可以直觀地觀察到 pod/ 容器中的進程因為發生直接內存回收和直接內存規整而被阻塞的時長。
- 查看 SysOM 容器系統監控-節點維度中的 System Memory 中的 Memory Others 大盤，可以觀察到節點上是否發生了直接內存回收。
具體指標解析
- Memory Others
該大盤中的 pgscan_direct 折線表示節點中在直接內存回收階段掃描的頁數，只要該折線的數值不為 0，説明在節點中發生了直接內存回收。
- Memory Direct Reclaim Latency
該大盤表示：當前採樣點與上一採樣點，由於容器內存使用量達到容器內存限制或者節點內存可用內存低於節點內存水位導致的容器中發生的直接內存回收在不同阻塞時長的次數增量（如 memDrcm_lat_1to10ms 表示直接內存回收延時時間在 1-10ms 的增量次數。memDrcm_glb_lat_10to100ms 表示直接內存回收延時時間在 10-100ms 的增量次數）。
- Memory Compact Latency
該大盤表示：當前採樣點與上一採樣點，由於節點內存碎片太多導致的容器中無法申請連續內存而發生的直接內存規整次數增量。
問題解決
內存回收延時最直接的原因就是節點/容器內存資源緊張。要優化內存使用，就需要看清內存和用好內存：
- 要看清內存，可以通過阿里雲操作系統控制枱推出的功能-節點 /Pod 內存全景分析[2]，該功能對節點 /Pod 使用的內存進行了詳細的拆解，細粒度到每個 Pod 的詳細內存組成。通過 Pod Cache（緩存內存）、InactiveFile（非活躍文件內存佔用）、InactiveAnon（非活躍匿名內存佔用）、Dirty Memory（系統髒內存佔用）等不同內存成分的監控展示，發現常見的 Pod 內存黑洞問題。
- 要用好內存，可以通過 ACK 容器服務團隊推出 Koordinator QoS 精細化調度功能[3]，通過精細化調整容器的內存水線，提早進行異步回收，緩解直接內存回收帶來的性能影響。
CPU 延時監控
查看 SysOM 容器系統監控-節點維度中的 System CPU and Schedule 大盤：
具體指標解析
- WaitOnRunq Delay
該大盤表示系統中所有可運行進程在運行隊列中等待運行的時間的平均值；通過該大盤，用户可以瞭解到系統中是否存在調度延時情況，如果存在超過 50ms 的毛刺，就可以説明系統中存在比較嚴重的調度延時，大部分進程都無法得到及時的調度。
- Sched Delay Count
該大盤表示：系統沒有發生調度的時間分佈統計。（如 SchedDelay 100ms 表示：系統中有 100ms 沒有發生調度的次數統計）。如果觀察到 SchedDelay 100ms 折線發生了陡增，那麼可以説明系統中發生了長時間不調度，系統上的業務進程可能因為得不到調度而受到影響。
問題解決
造成系統調度延時的原因有很多，如在 CPU 中運行的任務在內核態運行時間過長，當前 CPU 出現長時間的關中斷等。如果需要進一步定位產生調度延時的具體原因，可以使用阿里雲操作系統團隊推出的產品-阿里雲操作系統控制枱中的調度抖動診斷[4]進行進一步的根因分析。
案例分析 - 快速定位由 CPU 延時導致的網絡抖動
背景：
某金融行業客户在ACK上創建的集羣中，某兩個節點中業務pod連接redis經常出現連接失敗報錯；在經過網絡同學的初步排查後，基本可以鎖定是由於節點內核收包慢（延時500ms+），導致redis客户端斷開連接。
問題識別定位：
- 通過查看網絡抖動應時間的 Sched Delay Count 大盤，可以看到在對應的時間點中，伴隨着多次 1ms 以上的 sched delay，這説明了系統中這個時間點發生多次某個 CPU 不發生調度 500ms 以上，那麼很有可能 ksoftirq 得不到調度從而引發了網絡延時抖動。
- 通過操作系統控制枱的節點異常詳情，我們可以看到發生了調度抖動異常和 cgroup 泄漏異常：
- 查看操作系統控制枱中的調度抖動診斷的診斷報告，獲得瞭如下圖的診斷報告：
- 結合抖動診斷和 cgroup 泄漏異常基本可以確定是 memory cgroup 泄漏且 kubelt 訪問 memory cgroup 的 memory.numa_stat 文件時，由於 numa_stat 中的數據在 Alinux2 內核中多次遍歷 cgroup 層級導致調度抖動進而影響 softirq 收包。
- 最後結合操作系統團隊的 memory cgroup 泄漏工具分析，可以確定由於客户使用 cronjob 定時拉起容器讀取日誌導致 cgroup 泄漏（容器創建時會創建一個新的mem cgroup，讀取文件會產生page cache並統計在該cgroup中，容器退出後由於page cache未釋放使當前cgroup處於殭屍狀態，未被完全清除）。
問題解決：
所以問題從解決網絡抖動變為了解決 memory cgroup 泄漏問題：
1、臨時止血方法：通過 drop cache 回收 page cache，從而使對應的殭屍 cgroup被正常清除。
2、使用 Alinux 的自研特性，開啓殭屍 cgroup 回收功能；具體使用可參考[5]中“回收 zombie memcgs”章節。
您在使用操作系統控制枱功能的過程中，有任何疑問和建議，可以加入釘釘羣（羣號：94405014449）反饋，歡迎大家入羣交流。
參考鏈接：
[1]SysOM 內核層容器監控：
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/...
[2]操作系統控制枱內存全景分析：
https://help.aliyun.com/zh/alinux/user-guide/memory-panorama-...
[3]容器內存 QoS：
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/...
[4]阿里雲操作系統控制枱調度抖動診斷：
https://help.aliyun.com/zh/alinux/user-guide/scheduling-jitte...
[5]龍蜥操作系統資源隔離使用簡介：
https://openanolis.cn/sig/Cloud-Kernel/doc/659601505054416682
[6]阿里雲操作系統控制枱PC端鏈接：https://alinux.console.aliyun.com/
