Dataproc 2.0上Spark任务报错137及调度器异常的原因与解决方法

可能的原因 #

1. Exit code 137 相关 #

容器退出码137明确表示进程因内存不足被系统OOM Killer强制终止，常见场景包括：

• Spark executor分配的内存不足以承载任务处理的数据量，导致堆内存或堆外内存耗尽。
• Dataproc节点上的其他系统进程（如YARN ResourceManager、HDFS DataNode）占用过多内存，挤压了Spark容器的可用资源。
• 单个task处理的数据量过大，引发内存溢出。

2. "Could not find CoarseGrainedScheduler" 相关 #

这个报错是连锁反应：当executor意外退出后，其尝试与driver通信时，driver端的CoarseGrainedScheduler（Spark核心调度组件）已无法正常响应。根源通常是：

• 大量executor连续崩溃，导致driver的调度组件陷入异常状态。
• driver自身也面临内存或CPU资源不足，无法维护与executor的通信链路。

修复方法 #

调整Spark内存配置 #

• 增加executor内存：提交任务时通过--executor-memory参数调高内存配额，例如--executor-memory 10g；同时配合调整--executor-cores，避免单executor绑定过多核心导致内存竞争。
• 提升堆外内存：设置spark.executor.memoryOverhead参数，默认是executor内存的10%，如果任务涉及大量序列化、网络IO或第三方库调用，可手动指定为2g或更高，例如--conf spark.executor.memoryOverhead=2g。
• 限制driver内存：如果driver出现资源瓶颈，通过--driver-memory参数调整，例如--driver-memory 8g。

优化任务数据处理逻辑 #

• 拆分大分区：对输入数据执行repartition()或coalesce()，合理调整分区数量，确保单个task处理的数据量在内存可承载范围内。
• 提前过滤数据：在任务起始阶段过滤掉无用字段、冗余行，减少后续处理的数据规模。
• 避免宽依赖操作：尽量减少shuffle类操作（如join、groupBy），或通过广播小表优化join逻辑，降低内存消耗。

优化Dataproc节点资源 #

• 升级节点规格：如果当前节点内存配置过小，更换为内存更大的实例类型，例如从n1-standard-4切换到n1-highmem-8。
• 清理节点冗余负载：关闭节点上不必要的后台服务，释放系统内存资源。

排查与验证 #

• 查看节点dmesg日志，确认OOM Killer的触发记录，定位内存占用过高的进程。
• 启用Spark UI（默认端口4040），查看executor的内存使用趋势、task执行时长，精准定位内存瓶颈点。

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