Airflow容器内存未超请求阈值却遭OOM Kill的排查问询

可能的原因 #

• Python GC延迟与内存分配器特性：Python垃圾回收并非实时触发，若存在循环引用、或对象被全局模块（如日志、第三方库缓存）隐式持有，局部变量复用也无法自动回收。另外Python内存分配器（如pymalloc）会保留已释放内存块供后续复用，不会立刻归还操作系统，导致容器RSS（驻留集大小）持续走高，而Python层面的内存统计仅显示当前活跃对象占用。
• 内存峰值未被日志捕捉：日志仅记录循环末尾的内存值，但OOM可能发生在单次循环内部的处理峰值（比如数据加载、计算时瞬间内存冲高超过3Gi），峰值过后内存回落，日志未覆盖该时段。
• cgroup内存统计遗漏内核态占用：若仅查看用户态内存，未统计内核态内存（如页缓存、slab分配器占用），当任务频繁读写文件、网络IO时，内核内存会持续累积，最终Pod总内存（用户态+内核态）超出3Gi触发OOM。
• 第三方库内存泄漏：循环中调用的第三方依赖（如数据处理、HTTP库）可能存在未关闭的连接、未释放的资源缓存，这类对象不受局部变量控制，Python GC无法回收。
• Kubernetes内存配置不一致：需确认Pod的memory_limit是否与memory_request均设为3Gi，若仅设request未设limit，节点资源不足时会触发驱逐；若limit低于request，实际生效的是limit值，可能低于预期的3Gi。
• 子进程内存未被统计：循环中若启动子进程（如subprocess调用），子进程的内存占用不会被Python内存工具捕捉，但会计入Pod总内存，若子进程未正常退出或泄漏，会导致总内存超标。

调试方法 #

• 增加内存高频采样：在循环内部关键步骤（数据加载、处理前后）调用psutil.Process().memory_info().rss记录实时RSS内存，捕捉瞬间峰值。
• 手动触发GC并验证：在循环末尾执行gc.collect()，同时记录GC返回的回收对象数量，以及GC前后的内存变化，判断是否存在无法自动回收的对象。
• 查看完整cgroup内存数据：读取/sys/fs/cgroup/memory/memory.stat，关注total_rss、total_cache、total_slab等字段，计算总内存占用是否接近3Gi。
• 用tracemalloc追踪内存分配：在代码中加入内存快照对比，定位持续增长的对象来源：

  import tracemalloc
  tracemalloc.start()
  
  for idx in range(total_iterations):
      # 循环业务逻辑
      snapshot = tracemalloc.take_snapshot()
      top_stats = snapshot.statistics('lineno')
      print(f"Iteration {idx} Top 10 memory-consuming lines:")
      for stat in top_stats[:10]:
          print(stat)
  

• 验证Pod内存配置：执行kubectl describe pod <pod-name>，检查Resources字段下的Limits和Requests是否均设置为3Gi。
• 监控子进程状态：记录循环中启动的子进程PID，用ps aux查看子进程存活状态与内存占用，确认是否有残留或泄漏。
• 使用专业内存分析工具：在容器内安装memory-profiler或py-spy，对进程进行逐行内存分析或采样，定位内存增长的具体代码路径。

内容的提问来源于stack exchange，提问作者Hui