Spark未使用全部配置存储内存，达342MB时会话崩溃如何解决

• 优先校验配置实际生效值，不要以本地写的配置参数为准：所有内存类核心配置必须在SparkSession初始化前传入，初始化后通过spark.conf.set()设置的内存参数不会生效。直接打开Spark UI的Environment页签核对运行时参数：
  • 确认spark.executor.memory实际值为你配置的5GB，如果显示默认值1GB，说明参数传参位置错误（比如写在代码里SparkSession声明之后、提交参数漏写、被spark-defaults.conf里的默认值覆盖）。1GB默认executor内存下，存储内存池实际大小约300~360MB，和你观测到的342MB阈值完全吻合。
  • 确认spark.memory.fraction、spark.memory.storageFraction参数值：你之前用5GB*0.6*0.9计算可用存储内存的公式是错的，Spark 2.x之后的统一内存模型中，spark.memory.storageFraction默认值为0.5，0.9是1.6及更早版本的旧参数，已经废弃多年。
• 排查PySpark进程隔离导致的内存统计偏差：如果是用PySpark实现图像预测逻辑，Spark UI显示的Storage Memory只统计JVM堆内的存储内存占用，Python worker进程的内存完全不纳入该指标统计：
  • 默认spark.python.worker.memory阈值为512MB，Python进程内存达到该值时会触发溢写磁盘，如果图像二进制对象解码后膨胀率高、溢写路径权限异常/磁盘满，就会直接OOM崩溃，此时JVM侧存储内存通常只占用几百MB，刚好匹配你观测到的现象。
  • 如果预测逻辑用到PyTorch、TensorFlow等深度学习框架，框架生成的张量内存分配在堆外，默认堆外内存上限仅384MB左右，这部分内存也不会出现在Storage Memory统计项中，内存打满后直接崩溃。
• 排查任务并行度问题：如果读数据时分区数过低，哪怕总内存足够，单分区承载的数据解码后（图像解码后内存是磁盘文件大小的3~10倍）会直接打穿单任务内存阈值。重点检查代码中是否存在coalesce(1)、collect()这类将全量数据汇聚到单点的算子，这类算子会绕过内存池管理直接占用进程内存。

• 核心内存参数（全部通过spark-submit的--conf传入，或写在SparkSession初始化的config项中，禁止初始化后修改）：

# 单executor内存与CPU按4GB:1核配比即可，根据节点资源调整
--executor-memory 5g
--executor-cores 4
# 堆外内存开3~4G，供深度学习框架、Python序列化使用
--conf spark.executor.memoryOverhead=4g
# Python worker内存调整为2G，匹配单任务图像解码、预处理的内存需求
--conf spark.python.worker.memory=2g
# 适当提高统一内存占比，压缩用户预留内存空间
--conf spark.memory.fraction=0.7
# 存储内存占比保持0.5即可，图像预测场景执行内存需求更高
--conf spark.memory.storageFraction=0.5
# 关闭Python进程自动复用的内存泄漏风险
--conf spark.python.worker.reuse=false

• 任务逻辑调整：
  • 图像数据读取完成后，调用repartition(executor总数 * 单executor核数 * 2)调整分区数，保证单分区解码后的图像数据总大小不超过500MB，避免单任务OOM。
  • 不要直接缓存原始二进制图像数据，预处理完成后选择MEMORY_AND_DISK_SER级别缓存序列化后的张量数据，内存不足时自动溢写磁盘，不会触发OOM。
  • 预测用到的模型文件通过广播变量分发到各executor，禁止在map类算子中重复加载模型，避免冗余内存占用。
• 验证步骤：配置提交后先在Spark UI的Environment页签确认所有参数生效，再用小批量数据测试，观察Executor页签的各内存指标是否随数据量正常上涨，没有卡在342MB固定阈值即可。

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