Pinterest 工程师消除 CPU 僵尸进程,解决生产环境瓶颈
Pinterest 发布技术报告,详述如何解决分布式计算平台 PinCompute 上由“僵尸”cgroups 导致的间歇性 CPU 资源饥饿及网络故障问题。 故障根源在于基础镜像中默认启用的 Amazon ECS 代理在崩溃循环中泄漏内存控制组,导致活跃 memcgs 仅 240 个时,僵尸 memcgs 却累积近 70,000 个。 泄漏导致 kubelet 进程 CPU 占用率从不足 1% 飙升至约 6.5%,触发 ENA 设备重置,使特定训练任务成功率下降超过 25%。 解决方案为在基础镜像中禁用 ECS 代理的 systemd 单元并重启受影响机器以清除累积的 cgroups,从而恢
深度分析
TL;DR
- Pinterest 发布技术报告,详述如何解决分布式计算平台 PinCompute 上由“僵尸”cgroups 导致的间歇性 CPU 资源饥饿及网络故障问题。
- 故障根源在于基础镜像中默认启用的 Amazon ECS 代理在崩溃循环中泄漏内存控制组,导致活跃 memcgs 仅 240 个时,僵尸 memcgs 却累积近 70,000 个。
- 泄漏导致 kubelet 进程 CPU 占用率从不足 1% 飙升至约 6.5%,触发 ENA 设备重置,使特定训练任务成功率下降超过 25%。
- 解决方案为在基础镜像中禁用 ECS 代理的 systemd 单元并重启受影响机器以清除累积的 cgroups,从而恢复平台稳定性。
- 报告强调生产环境可观测性的价值,指出团队正与英特尔合作开发 gProfiler,并推荐基于 eBPF 的工具(如 Parca、Grafana Pyroscope)以缩短故障排查路径。
为什么值得看
这篇文章为大规模分布式系统中的疑难杂症排查提供了极具价值的案例,展示了如何透过表象(网络故障)洞察底层内核机制(CPU 核心饱和与 cgroup 泄漏)。它对 AI 从业者而言,不仅是 MLOps 基础设施稳定性的警示,更提供了从高级仪表盘到逐核分析(mpstat)及火焰图(Flamescope)诊断的完整方法论,对于构建高可用性训练集群具有直接指导意义。
关键数据
- 成功率下降幅度:在某些用例中,由于 ENA 设备重置和数据包丢失,训练任务的成功率下降了超过 25%。
- 僵尸 cgroups 数量:调查中发现,活跃使用的内存控制组(memcgs)仅有 240 个,而“僵尸”memcgs 累积了将近 70,000 个。
- CPU 占用率变化:原本 CPU 占用率不足 1% 的 kubelet 进程,在故障发生时飙升至约 6.5%,大部分时间耗费在内核函数 mem_cgroup_nr_lru_pages 中。
- 规模与频率:PinCompute 平台每月为离线机器学习任务预配数万个 Ray 集群,承载 Pinterest 超过一半的离线机器学习工作负载。
- 监控窗口:团队利用 12 小时重现窗口,每两分钟运行一次性能捕获以定位问题。
技术解析
- 故障机制:问题表现为间歇性网络故障。当处理 ENA(弹性网络适配器)网络中断的 CPU 内核因 kubelet 遍历庞大 cgroup 列表而饱和时,NAPI 轮询线程受阻,导致 ENA 设备重置(停滞超过 5 秒触发的自愈机制),进而引发数据包丢失和 Ray 任务崩溃。
- 根因分析:根因追溯至 AWS 深度学习 AMI 中默认启用的 Amazon ECS 代理。由于 Pinterest 未使用该代理,其在每次重启时陷入崩溃循环并泄漏 cgroups,导致 kubelet 在同步状态时独占内核长达数秒,表现为系统 CPU 使用率在个别内核上连续数秒达到 100%。
- 诊断方法:由于高级仪表盘显示的汇总 CPU 利用率正常,团队转用 mpstat 进行逐核分析,并在 12 小时窗口内每 2 分钟采集性能数据,通过 NetflixFlamescope 可视化火焰图,精准捕捉到网络重置时刻 kubelet 的 CPU 异常及 mem_cgroup_nr_lru_pages 函数的耗时。
- 修复方案:通过在基础镜像中禁用 ECS 代理的 systemd 单元,并重启受影响机器以清除累积的“僵尸”cgroups,使内存 cgroup 数量稳定,彻底消除网络重启现象。
行业启示
- 审视基础镜像默认配置:在大规模集群中,基础镜像的默认组件(如未使用的代理)可能成为隐蔽的性能瓶颈。工程师需对系统默认设置持质疑态度,定期审计镜像中的冗余守护进程,防止其引发内核状态泄漏。
- 深化底层可观测性:传统的汇总指标往往掩盖细粒度的内核饱和问题。行业趋势正转向持续、按时间索引的分析,利用 eBPF 等技术提供集群全局可见性,实现从症状到根因的实时关联,而非依赖事后手动排查。
- 跨层系统思维的重要性:AI 基础设施的稳定性不仅取决于应用代码,更受制于操作系统、网络驱动与编排器之间的交互。掌握从用户空间到内核空间的诊断工具链(如 mpstat、Flamescope)是解决高并发环境下间歇性故障的关键能力。
zon ECS 代理的 systemd 单元,然后重启受影响的机器。重启操作清除了累积在近 70,000 个的“僵尸”内存控制组,使 cgroup 数量稳定在正常水平,从而阻断了泄漏源头。
Q: Pinterest 推荐使用哪些工具来提升未来生产环境的可观测性?
A: 团队推荐提供集群范围全局可见性的工具,包括他们与英特尔合作开发的 gProfiler,以及基于 eBPF 的平台如 Parca 和 Grafana Pyroscope。这些工具能够缩短从症状到根本原因的排查路径,支持实时识别问题模式。
免责声明:以上内容由 AI 生成,仅供参考。
常见问题
为什么高级仪表盘显示的 CPU 利用率正常,却未能发现 CPU 资源饥饿问题? ▾
因为汇总的 CPU 利用率是平均值,掩盖了个别 CPU 内核在短时间内的饱和现象。问题根源在于 kubelet 遍历庞大 cgroup 列表导致特定处理网络中断的内核饱和,这种细粒度的瞬时瓶颈在常规监控中不可见,需通过 mpstat 进行逐核分析才能发现。
“僵尸”cgroups 是如何被清理的? ▾
团队首先在基础镜像中禁用了导致泄漏的 Ama
相关文章
每天接收最值得关注的 AI 信号
加入 1000+ 创始人、投资人和技术从业者。每天早上直达邮箱:精选 AI 动态、深度分析、值得关注的二阶变量。
无垃圾邮件,随时退订。