在分散式運算環境中，我們經常依賴高層級的監控面板來觀察系統健康狀況。然而，Pinterest 工程團隊最近分享的一個案例提醒我們：當平均 CPU 使用率看起來很正常時，系統底層可能正發生著足以導致服務崩潰的嚴重問題。
這次的問題發生在 Pinterest 的 PinCompute 平台上，這是一個基於 Kubernetes 的環境，承載了超過一半的離線機器學習訓練工作。他們發現部分訓練任務的成功率大幅下降，甚至跌破 75%，而表象則是頻繁出現的網路連線失敗與工作崩潰。
隱藏在網路問題背後的 CPU 飢餓死現象
最初的調查陷入僵局，因為從監控面板看到的整體 CPU 使用率非常健康。但工程師意識到，平均值會掩蓋單核的極端情況。他們改用 mpstat 進行單核分析，發現某些 CPU 核心會突然在數秒內衝到 100% 的 System CPU 使用率。
這在網路傳輸中是非常致命的。Pinterest 使用 AWS 的 Elastic Network Adapter (ENA) 網路卡。當負責處理網路中斷（Interrupts）的 CPU 核心被佔滿時，驅動程式的 NAPI poll thread（一種用來高效處理封包的機制）會因為拿不到 CPU 週期而陷入飢餓狀態。
當 ENA 驅動程式發現傳送完成信號（Tx completions）停滯超過五秒，會觸發一種自我修復機制，直接重置網路設備。這次重置導致連線中斷，進而導致執行在 Ray 框架上的機器學習任務集體崩潰。
追蹤 CPU 尖峰的根源
為了找出到底是誰佔用了 CPU，團隊採取了滾動式採樣，在 12 小時的還原窗口內每兩分鐘執行一次 perf capture。接著利用 Netflix 開源的 Flamescope 視覺化工具，將性能分析數據與網路重置的時間點對齊。
分析結果出乎意料：平時 CPU 佔用率不到 1% 的 kubelet 進程，在出事瞬間會飆升至 6.5%。進一步深入核心函數，發現 CPU 時間幾乎全部消耗在 mem_cgroup_nr_lru_pages 這個核心函數中。
這意味著 kubelet 在同步 cgroup 統計資訊時，必須遍歷一個異常龐大的列表。
揭開 CPU 殭屍的真面目
問題的根源出在 AWS Deep Learning AMI（預設的機器映像檔）。該映像檔預裝了 Amazon ECS Agent，但 Pinterest 並未使用此服務。然而，這個 Agent 在背景處於 Crashlooping 狀態，也就是不斷崩潰又不斷重啟。
每次 Agent 重啟時，都會洩漏（Leak）記憶體 cgroup（memcgs，這是 Linux 核心用來限制與監控進程記憶體使用的機制）。隨著時間推移，系統中積累了近 70,000 個不再使用但未被刪除的記憶體 cgroup，而實際在運行的僅有 240 個。
這些被遺忘的 cgroup 就像殭屍一樣殘留在核心中。每當 kubelet 嘗試同步狀態時，必須走訪這 7 萬個項目，導致單個 CPU 核心被瞬間佔滿，進而引發連鎖反應：CPU 飽和導致網路驅動飢餓，驅動飢餓導致網卡重置，最終導致任務崩潰。
實務啟示與解決方案
解決方法相對簡單：在基礎映像檔中禁用 ECS Agent 的 systemd 單元，並重啟機器以清除殘留的 cgroup。此舉後，記憶體 cgroup 數量恢復穩定，網路重置現象也隨之消失。
這個案例給工程師三個重要的實務啟示：
第一，不要過度信任平均值。高層級的 Dashboard 適合監控趨勢，但排查性能瓶頸時，必須深入到單核、單線程的層級。
第二，警惕預設配置。許多雲端供應商提供的 AMI 為了通用性會開啟許多預設服務，這些不必要的背景進程可能會在規模化後演變成嚴重的系統漏洞。
第三，建立連續的性能分析能力。手動執行 perf 採樣在這次案例中有效，但對於大規模集群，需要像 gProfiler 或基於 eBPF 的 Parca 與 Grafana Pyroscope 這種能提供全集群、時間索引化分析的工具，才能將從症狀到根因的追蹤時間縮短。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。