Spark Executor JVM崩溃问题：EMR集群运行逻辑回归代码异常

我之前在AWS EMR上跑Spark ML分类模型时，也碰到过一模一样的Executor JVM崩溃问题，结合你的集群配置（1主节点+4工作节点，每节点4核16GB内存），咱们从几个核心方向排查解决：

1. 优化Executor资源分配（最常见的原因） #

你的工作节点是4核16GB，默认Spark的资源分配往往不是最优的，很容易因为内存不足或CPU过载导致崩溃：

• 给每个Executor分配3核CPU（留1核给节点的系统进程，避免资源抢占），12GB堆内存（预留4GB给系统和JVM堆外开销）
• 同时一定要设置executor.memoryOverhead（堆外内存），建议2GB，防止JVM堆外内存溢出：
  提交作业时可以加这些参数：

  spark-submit --executor-cores 3 --executor-memory 12G --driver-memory 8G --conf spark.executor.memoryOverhead=2G your_script.py
  

  或者在代码里通过SparkConf设置：

  from pyspark import SparkConf, SparkContext
  conf = SparkConf()
  conf.set("spark.executor.cores", "3")
  conf.set("spark.executor.memory", "12G")
  conf.set("spark.driver.memory", "8G")
  conf.set("spark.executor.memoryOverhead", "2G")
  sc = SparkContext(conf=conf)
  

2. 调整数据分区，降低Shuffle压力 #

逻辑回归、随机森林这些模型在训练过程中会有大量Shuffle操作，如果数据分区不合理，单个Executor要处理的数据量过大，很容易OOM：

• 先检查当前数据的分区数：print(df.rdd.getNumPartitions())
• 建议把分区数设置为总Executor核心数的2-3倍（你的总核心是4节点×3核=12，所以设置24-36个分区比较合适）
• 重新分区：df = df.repartition(30)
• 开启Shuffle压缩，减少磁盘IO和内存占用：

  conf.set("spark.shuffle.compress", "true")
  conf.set("spark.shuffle.spill.compress", "true")
  

3. 调优模型参数，减少计算负载 #

默认的模型参数可能导致计算量过大，尤其是逻辑回归：

• 减少迭代次数：比如把maxIter从默认的100降到20-50（很多场景下20次就足够收敛）：

  lr = LogisticRegression(maxIter=20, regParam=0.1)
  

• 增加正则化参数regParam（比如0.1），防止模型过于复杂，降低计算压力
• 如果你的特征维度很高，先做特征选择（比如用VectorSlicer筛选重要特征，或者PCA降维），减少特征数量能大幅降低计算量

4. 检查YARN资源配置与日志 #

EMR基于YARN调度，YARN的配置也可能影响Executor的稳定性：

• 确保YARN的yarn.nodemanager.resource.memory-mb设置为16384MB（对应16GB），yarn.nodemanager.resource.cpu-vcores设置为4，和节点硬件匹配
• 去EMR控制台的“日志”模块，查看Executor的崩溃日志，找具体的错误信息（比如明确的OutOfMemoryError，或者GC超时），这能帮你精准定位问题

5. JVM垃圾回收（GC）优化 #

如果是GC停顿时间过长导致Executor被YARN杀掉，可以调整JVM的GC参数：

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

G1GC是适合大内存场景的垃圾回收器，能有效减少GC停顿时间，避免因为GC超时导致Executor被标记为失败

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