深度解析:如何通过CPU瓶颈发现系统中的「僵尸进程」?Pinterest的真实案例
在现代云计算和大数据时代,任何一家科技公司都无法避免系统性能问题的困扰。然而,当问题出现时,如何快速定位根因并彻底解决,往往考验着工程师们的智慧与耐心。Pinterest作为全球知名的图片分享平台,其工程团队在2025年初就遭遇了这样一个棘手的系统问题:他们的机器学习训练作业频繁崩溃,而背后的原因竟然是系统中的「僵尸进程」!这场长达三个多月的调查不仅揭开了CPU瓶颈的真相,还为整个行业提供了宝贵的性能优化经验。**Ray框架在Pinterest的重要性**Pinterest的机器学习平台团队近年来大力推动Ray框架的应用,将其打造成公司下一代机器学习训练和推理的核心基础设施。Ray以其高效的分布式计算能力和灵活的任务调度机制,成功支撑了公司超过一半的离线机器学习工作负载。凭借Ray的强大功能,Pinterest实现了系统规模的扩展,加速了模型实验的迭代,并显著提升了服务用户的AI模型性能。
然而,随着Ray集群规模的不断扩大,新的挑战也随之而来。特别是在处理大规模分布式训练任务时,网络稳定性成为影响系统整体性能的关键因素。Pinterest的工程团队发现,他们的Ray训练作业在运行过程中时常出现网络连接中断的情况,最终导致作业崩溃。这种不稳定性不仅浪费了昂贵的GPU计算资源,还严重阻碍了模型开发和实验的进度。**从网络中断到CPU瓶颈的调查之旅**问题的最初线索来自ML平台团队的求助。他们报告称,Ray训练作业在运行过程中频繁出现网络连接丢失的情况,导致作业失败率超过25%。
经过初步排查,工程团队发现这些网络中断与AWS ENA(Elastic Network Adapter)网络驱动的重置事件高度相关。每当网络驱动重置发生时,Ray集群的网络连接就会出现短暂中断,进而导致训练作业崩溃。根据AWS官方文档,ENA网络驱动的重置是一种自愈机制,当驱动检测到设备异常行为时(如Tx线程长时间暂停、网络设备无响应等)就会触发。然而,这种重置虽然持续时间极短(通常不超过1毫秒),但在重置过程中会导致部分网络流量丢失。虽然传输协议通常能够恢复这些丢失的流量,但在Ray这种高度依赖网络通信的系统中,即使微小的网络中断也可能引发严重后果。**CPU starvation:隐藏的性能杀手**在排查过程中,工程团队注意到一个关键现象:在出现网络驱动重置的机器上,系统CPU使用率普遍较高。
根据AWS ENA文档的解释,Tx线程长时间暂停可能是由CPU starvation引起的,即网络驱动线程无法及时获得CPU时间片。这意味着系统中可能存在某些CPU密集型进程,长时间占用CPU资源,导致网络驱动线程被饿死。为了验证这一假设,工程团队尝试了多种优化措施:启用大页内存以减少页面错误、使用更高效的内存分配器(如jemalloc)、为训练作业分配专用CPU核心、调整网络中断的CPU亲和性等。然而,这些措施虽然在一定程度上降低了整体CPU使用率,但网络驱动重置的问题依然存在。更令人困惑的是,这种问题有时在作业运行初期就出现,有时却要等到几小时后才发生,完全无法预测。**可用区差异:隐藏的线索**在持续的调查过程中,工程团队发现了一个奇怪的现象:网络驱动重置问题仅出现在AWS的us-east-1a可用区内,而在其他可用区运行的同类作业却完全正常。
这意味着问题可能与特定的硬件环境或配置有关。然而,经过与AWS技术支持团队的深入沟通,Pinterest的工程团队确认问题并不在AWS侧。AWS的分析结果显示,us-east-1a可用区内的机器在CPU使用方面存在异常,这与之前的CPU starvation假设不谋而合。那么,是什么原因导致特定可用区的机器出现CPU过载呢?**深度性能分析:从宏观到微观**为了找到问题的根本原因,工程团队决定深入分析系统的CPU使用情况。他们首先使用perf工具进行性能分析,但发现常规的性能快照并不能提供足够的信息。因为在拥有96个vCPU核心的GPU机器上,整体的CPU使用率统计无法揭示单个核心的异常行为。
于是,团队转而使用mpstat工具,以每秒为单位监控每个CPU核心的使用情况。经过长时间的数据收集和分析,他们发现有时某个特定的CPU核心(例如核心39)会在数秒内100%占用系统CPU资源。更关键的是,这种异常现象与网络驱动重置事件高度吻合。然而,由于网络驱动重置的发生时间具有不确定性,团队无法及时捕捉到重置发生时的性能数据。为了解决这一问题,他们设计了一种临时性的解决方案:在保留机器上连续运行perf工具,以收集长时间段的性能数据。通过这种方式,他们能够在网络驱动重置发生后回溯分析,找出重置前后的CPU使用情况。
**时间旅行式调试:锁定罪魁祸首**为了更精确地分析问题,工程团队借鉴了Netflix开源的Flamescope工具,实现了时间旅行式的性能分析。通过这种方式,他们能够在特定的时间窗口内查看CPU栈的详细信息。分析结果令团队震惊:在网络驱动重置发生前的几秒钟内,Kubernetes的kubelet进程突然占用了约6.5%的CPU资源。而在正常情况下,kubelet的CPU使用率通常不超过1%。进一步深入分析发现,kubelet在这段时间内频繁调用了mem_cgroup_nr_lru_pages系统调用,这意味着系统正在遍历所有内存cgroup。**内存cgroup的「僵尸」危机**就在这时,团队偶然发现了一篇关于Oracle博客的文章,描述了内存cgroup「僵尸」问题。
根据文章描述,当系统中存在大量死亡的cgroup时,内核在遍历cgroup列表时会消耗大量CPU资源。这与团队在Pinterest系统中观察到的现象完全吻合。为了验证这一假设,团队在出现网络驱动重置的机器上检查了内存cgroup的数量:bash# 内核跟踪的cgroup(包括僵尸)$ cat /proc/cgroups | grep memory | awk '{print $3}'68680# 实际存在的cgroup$ find /sys/fs/cgroup/memory/ -type d | wc -l240```结果显示,内核跟踪的cgroup数量高达68,680个,而实际存在的cgroup仅有240个。这意味着系统中存在大量「僵尸」cgroup,而kubelet在遍历这些cgroup时消耗了大量CPU资源。如果网络驱动的线程恰好在这些CPU核心上运行,就会被饿死,进而触发ENA网络驱动的重置机制。**揪出幕后黑手:Amazon ECS Agent**那么,这些「僵尸」cgroup是如何产生的呢?团队进一步调查发现,系统中存在一个名为Amazon ECS Agent的进程。
这个进程原本用于AWS ECS(Elastic Container Service)集群的管理,但在Pinterest的Kubernetes环境中并未使用。然而,Pinterest的GPU实例使用了AWS Deep Learning AMI作为基础镜像,而这个镜像默认启动了ECS Agent。由于Pinterest的机器没有ECS集群的访问权限,ECS Agent在启动后无法连接到ECS集群,导致其不断重启并创建新的cgroup。经过数天的累积,这些「僵尸」cgroup数量激增,最终引发了CPU瓶颈问题。**根本解决方案与意外发现**为了彻底解决这一问题,Pinterest的工程团队采取了两个关键措施:1. **禁用ECS Agent**:通过修改基础镜像的systemd配置,禁用ECS Agent的自动启动。这一措施直接切断了「僵尸」cgroup的来源,从根本上解决了CPU瓶颈问题。
2. **清理现有僵尸cgroup**:通过重启机器,清理系统中已有的「僵尸」cgroup。由于重启会重置cgroup计数器,这一措施能够立即缓解系统压力。经过这些修复措施后,Pinterest的Ray训练作业成功率恢复到正常水平,网络驱动重置问题也彻底消失。这不仅解决了当前的性能问题,还为未来的系统优化积累了宝贵经验。然而,故事到这里并没有结束。在调查过程中,团队还发现了另一个意外的细节:为什么网络驱动重置问题仅出现在us-east-1a可用区内?经过更深入的调查,他们发现us-east-1a可用区的Kubernetes集群在节点引导脚本中存在一个配置差异。
由于脚本执行失败,ECS Agent的systemd单元未能正确启动,从而避免了「僵尸」cgroup的累积。这一发现不仅解释了可用区差异的原因,也为未来的自动化部署工具开发提供了重要参考。**关键经验与最佳实践**Pinterest的这段经历为整个行业提供了宝贵的性能优化经验。以下是团队总结的几点关键经验:**1. 建立全面的系统监控体系**在现代分布式系统中,瞬时故障往往难以捕捉。Pinterest的团队通过建立全面的系统监控体系,特别是针对网络驱动重置等瞬时事件的监控,能够及时发现问题并分析故障模式。这种主动监控的思维方式对于快速定位和解决系统问题至关重要。
**2. 投资高级性能分析工具**传统的性能分析工具(如perf)虽然强大,但在处理间歇性问题时往往力不从心。Pinterest的团队通过结合mpstat和Flamescope等工具,实现了时间旅行式的性能分析,能够在问题发生时精确回溯系统状态。未来,他们计划在整个系统中部署gProfiler等高级性能分析工具,以提升问题排查的效率和准确性。**3. 关注系统默认配置的影响**许多系统问题实际上源于默认配置的不匹配。Pinterest的案例中,AWS Deep Learning AMI的默认配置(启用ECS Agent)与Kubernetes环境不兼容,最终导致了严重的系统问题。因此,工程团队在构建系统镜像时,必须仔细审查所有默认配置,确保其与实际运行环境相匹配。
**4. 重视系统进程的健康状态**系统中的进程(特别是systemd单元)如果频繁崩溃或重启,可能会导致资源泄漏或异常行为。Pinterest的团队通过监控ECS Agent的运行状态,及时发现了「僵尸」cgroup的问题。未来,他们计划加强对系统进程健康状态的监控,及时发现并处理异常情况。**5. 确保环境一致性**在云计算环境中,即使看似相同的配置,也可能由于细微差异导致完全不同的行为。Pinterest的案例中,us-east-1a可用区与其他可用区的差异源于一个未被注意的配置细节。因此,工程团队必须投资自动化工具,确保所有环境的配置完全一致,避免因环境差异导致的问题。
**对未来系统优化的启示**Pinterest的这段经历不仅解决了一个具体的系统问题,还为整个行业提供了宝贵的性能优化经验。在当今云原生和大数据时代,系统复杂性不断提升,性能问题往往隐藏在看似正常的系统运行背后。通过建立全面的监控体系、投资高级性能分析工具、关注系统默认配置、重视进程健康状态以及确保环境一致性,工程团队能够更快速地定位和解决系统问题,确保系统的稳定性和可靠性。对于其他正在面临类似问题的公司,Pinterest的经验提供了以下建议:- **建立问题复现环境**:通过创建可复现的调试环境,工程团队能够在受控条件下分析问题,提高问题排查的效率。- **重视时间维度的性能分析**:间歇性问题往往需要长时间、高频率的数据收集才能发现规律。因此,投资时间旅行式的性能分析工具(如Flamescope)对于解决此类问题至关重要。
- **关注系统底层机制**:许多性能问题实际上源于系统底层机制(如内存管理、cgroup管理等)的异常行为。因此,深入理解系统底层机制对于问题排查具有重要意义。- **加强跨团队协作**:Pinterest的案例中,PinCompute团队与ML平台团队的紧密合作是成功解决问题的关键。因此,建立跨团队的协作机制,能够有效提升问题排查的效率和质量。**结论**Pinterest的「僵尸进程」案例是一个典型的系统性能问题,其复杂性在于问题的隐蔽性和间歇性。通过深入的性能分析、全面的系统监控和跨团队的协作,工程团队最终揭开了问题的真相,并提出了根本性的解决方案。
这一经历不仅为Pinterest的系统优化提供了宝贵经验,也为整个行业提供了重要的参考。在当今快速发展的科技环境中,系统性能问题无法避免,但通过科学的方法论、先进的工具和平台化的思维,工程团队能够更从容地应对这些挑战。Pinterest的案例告诉我们,即使最复杂的问题,也能通过系统性的分析和创新的思维找到解决方案。 。
