北京
作者 ｜ Mark Silvester
譯者 ｜ 平川
Pinterest 發布了 一份詳細的技術報告，闡述他們的工程師如何追蹤并解決了導致機器學習訓練任務崩潰的間歇性 CPU 資源饑餓問題。通過識別團隊所說的“僵尸”（即由崩潰循環的默認代理所留下的內存泄漏 cgroups），工程師們成功地恢復了分布式計算平臺的穩定性。
該問題表現為間歇性網絡故障以及在 PinCompute 上的任務崩潰。PinCompute 是一個基于 Kubernetes 的平臺，Pinterest 超過一半的離線機器學習工作負載都在該平臺上運行。它每月會為這些任務預配數萬個 Ray 集群。在某些用例中，由于彈性網絡適配器（ENA）設備重置和數據包丟失，訓練任務的成功率下降了超過 25%。初步調查工作遇到了麻煩，因為匯總的 CPU 利用率看起來很正常，掩蓋了底層的故障。
由于無法通過高級儀表盤進行監控，基礎設施團隊轉而使用 mpstat 進行逐核分析。調查發現，個別內核的系統 CPU 使用率會連續數秒達到 100%。這種行為非常棘手，因為如果處理 ENA 網絡中斷的某個內核達到飽和狀態，驅動程序的 NAPI 輪詢線程就可能會因為缺乏處理周期而受阻，從而觸發 ENA 設備重置（這是一種事務完成操作停滯超過五秒時啟動的自愈機制），進而導致連接中斷，最終使 Ray 任務崩潰。
為了準確定位導致內核飽和的根源，團隊利用了在 12 小時重現窗口內每兩分鐘運行一次的性能捕獲。通過在 Netflix Flamescope 中可視化這些捕獲的數據，工程師們得以深入查看網絡重置觸發的確切時刻。他們發現，通常情況下 CPU 占用率不足 1% 的 kubelet 進程，此時卻飆升至約 6.5%。其中大部分時間都耗費在內核函數 mem_cgroup_nr_lru_pages 中。
調查最終將問題追溯到了其節點所使用的 AWS 深度學習 AMI。該基礎鏡像中包含一個默認啟用的 Amazon ECS 代理，但 Pinterest 并未使用該代理。在每次重啟時，該代理都會陷入崩潰循環并泄漏內存控制組（memcgs）。活躍使用的 memcgs 僅有 240 個，而“僵尸”memcgs 卻累積了近 70000 個，這導致 kubelet 在每次 cgroup 狀態同步時都必須遍歷這份膨脹的列表，從而獨占一個內核多達數秒之久。
該問題的解決方法相對簡單，但需要對系統堆棧有一個深入的理解。為了解決了這一瓶頸，Pinterest 在基礎鏡像中禁用了 ECS 代理的 systemd 單元，并重啟受影響的機器來清除累積的 cgroups 。自此之后，內存 cgroup 的數量穩定了下來，網絡重啟現象也沒有再出現。這一經驗表明，應用程序、編排器與內核之間的抽象層往往會掩蓋真正的原因：在這個案例中，正是冗余的用戶空間守護進程導致了內核狀態泄漏。
雖然 Pinterest 這次是通過手動分析來解決問題的，但團隊也意識到，就生產環境的可觀測性而言，持續的、按時間索引的分析具有重要的價值。諸如 gProfiler（Pinterest 目前正與英特爾合作開發）以及基于 eBPF 的平臺（如 Parca 和 Grafana Pyroscope）這樣的工具，能夠提供集群范圍的全局可見性，從而縮短從癥狀到根本原因的排查路徑，使工程師能夠實時識別問題模式，而不必在故障發生后手動進行排查。
通過分享研究成果，Pinterest 工程團隊強調，通常來說，在規模比較大的環境中，性能表現不僅取決于應用程序代碼，也很大程度上取決于基礎鏡像的默認配置。他們的實踐經驗為軟件工程師們敲響了重要的警鐘：要對系統默認設置持質疑態度，并熟練掌握底層診斷工具。
https://www.infoq.com/news/2026/05/pinterest-cpu-zombies-bottleneck/
會議推薦
Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？
AICon 上海站 2026，13 大重磅專題已上線，誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。快來掃碼鎖定 8 折專屬席位或提交演講議題
今日薦文
你也「在看」嗎？
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
