Azure Databricks Spark任务Executor被杀死及连接重置问题求助

核心问题定位 #

你遇到的Executor decommission: worker decommissioned because of kill request from HTTP endpoint是关键错误，说明Executor是被Databricks控制平面或Azure平台主动终止的，并非任务自身的内存溢出或网络异常导致崩溃。Connection reset by peer警告是Executor被杀死后，Driver与Executor连接中断引发的连锁反应，无需单独处理。

可能的根源及解决方法 #

1. Workflow任务超时限制触发终止 #

• 原因：Azure Databricks Workflows默认任务超时时间为4小时，超过时长后会主动终止任务关联的Executor。
• 解决：
  • 在Workflows任务配置页，找到「超时」选项，将时间调整为大于任务实际运行时长（比如设置为6小时）；
  • 若通过API提交任务，修改timeout_seconds参数（默认14400秒）为更大值。

2. 集群自动终止配置误触发 #

• 原因：若使用按需集群，配置的「空闲超时」过短，可能在任务运行中误判集群为空闲，触发自动终止；或集群设置了固定生命周期时长。
• 解决：
  • 进入集群配置页，临时禁用「自动终止」（适合长时间运行的任务）；
  • 若保留自动终止，将空闲超时调至3600秒以上，避免误判；
  • 检查集群「生命周期管理」设置，确保未配置固定终止时间。

3. Azure资源配额不足导致强制回收 #

• 原因：Azure订阅中，集群使用的VM实例类型配额不足，平台会强制回收超出配额的计算资源。
• 解决：
  • 登录Azure门户，进入「订阅」→「使用情况 + 配额」，查看对应VM实例的使用量是否接近配额；
  • 若配额不足，提交配额提升申请至Azure支持。

4. Spark配置不合理引发资源调度问题 #

• 原因：你设置的spark.scheduler.mode: FAIR若并非多任务共享集群的必需配置，可能导致资源调度冲突，引发Executor被回收；另外spark.driver.memory=210g过大，可能造成资源浪费或集群稳定性问题。
• 解决：
  • 若无多任务共享集群需求，将spark.scheduler.mode改回默认的FIFO；
  • 根据任务实际数据量调整spark.driver.memory（比如64g或128g，除非确实需要处理超大规模Driver端数据）；
  • 优化任务逻辑，排查是否存在数据倾斜、冗余计算等问题，缩短任务运行时长。

内容的提问来源于stack exchange，提问作者jacka-lope