Spark Executor JVM堆内存峰值问题排查求助

一、查看Pod内部进程内存 #

kubectl top pod仅能显示Pod整体资源使用，要排查内部进程内存，需直接进入Pod执行分析工具：

• 进入目标Executor Pod：

  kubectl exec -it <your-executor-pod-name> -- /bin/bash
  # 若镜像为Alpine等轻量版本，改用sh：
  kubectl exec -it <your-executor-pod-name> -- /bin/sh
  

• 查看Pod内进程内存排序，定位Spark Executor进程：

  ps aux --sort=-%mem
  

  找到进程名通常为org.apache.spark.executor.CoarseGrainedExecutorBackend的进程，记录其PID。
• 用JDK工具分析JVM堆内存细节：
  • 实时监控GC状态：

    jstat -gc <executor-pid> 1000 5
    

    观察S0U/S1U（Survivor区使用量）、EU（Eden区使用量）、OU（老年代区使用量）的变化，确认GC是否实际执行。
  • 查看堆内存配置与当前使用情况：

    jmap -heap <executor-pid>
    

二、排查Spark内存未释放原因 #

1. 缓存数据残留 #

Spark的persist/cache操作会将数据驻留内存，任务结束后不会自动清理：

• 若能访问Spark UI，进入Executor页面的Storage标签，检查是否有未释放的RDD/DataFrame缓存。
• 代码中对不再需要的缓存数据调用unpersist(true)，或配置spark.cleaner.referenceTracking.cleanCheckpoints=true自动清理checkpoint数据。

2. 代码层面内存泄漏 #

• 检查自定义代码：是否存在全局静态集合、未关闭的IO/数据库连接、UDF/累加器持有大量对象引用，导致GC无法回收。
• 排查第三方依赖：确认使用的第三方库是否存在内存泄漏（如连接池未正确释放）。

3. GC参数优化与手动触发 #

默认GC策略可能适配性不足，尝试调整并手动触发GC验证：

• 在Spark配置中替换高效GC策略：

  config("spark.executor.extraJavaOptions", "-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails")
  

• 手动触发GC，观察内存变化：

  jcmd <executor-pid> GC.run
  

  若内存仍未下降，说明存在无法被GC回收的对象。

三、深度定位内存泄漏 #

若手动GC无效，生成堆转储文件做进一步分析：

jmap -dump:format=b,file=executor_heap_dump.hprof <executor-pid>

将文件导出到本地，用Memory Analyzer Tool（MAT）或VisualVM打开，定位占用内存的大对象与未释放的引用链。

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