Spark作业提交后迟迟不开始跑——YARN资源分配怎么排查？

Spark手册第 5 题约 3 分钟读完

本文目录

先说结论

作业不开始跑的常见原因有三个：资源不够、队列配置不当、作业资源请求过大。

先把这段讲顺；面试官追问时，再展开下面的原理和细节。

详细讲解

Spark作业提交后迟迟不开始跑，是生产环境经常遇到的问题。很多人以为是Spark的问题，其实多数时候是YARN的资源问题。今天把排查思路和资源配置的核心参数讲清楚。

打开YARN ResourceManager的Web UI，看作业状态。如果状态是ACCEPTED而不是RUNNING，说明正在等待资源分配。

重点看：

• 集群总资源和已用资源（是不是已经满了？）

• 队列剩余资源（你的作业所在队列还有多少资源？）

• 作业请求的资源（你的作业要的资源是不是超过了队列剩余？）

参数	含义	建议值
--executor-memory	每个Executor的堆内存	看节点内存，通常4-8G
--executor-cores	每个Executor的CPU核数	4-5核（不要超过5）
--num-executors	Executor数量	按集群资源和作业需求定
--driver-memory	Driver内存	通常2-4G，有collect()时加大
spark.yarn.executor.memoryOverhead	堆外内存	executor-memory的10-15%

cluster模式： Driver跑在YARN集群的某个节点上。生产环境必须用这个——提交后可以关掉本地终端，Driver不会受影响。

client模式： Driver跑在提交作业的机器上。适合调试——可以直接看到Driver的日志输出。

我在元宇宙社交App时遇到过一次事故：有人用client模式提交了一个生产作业，结果他关了笔记本，Driver挂了，整个作业失败。从那以后我们规定生产环境必须用cluster模式。

我用的经验公式（假设集群每个节点有16核、64GB内存）：

• 每个Executor 5核、“16GB÷3 - 1GB”≇15GB内存（留一个核和部分内存给NodeManager）

• 每个节点跑3个Executor（(16-1)/5=3）

• 内存开销：15GB × 10% = 1.5GB，所以--executor-memory=13g，memoryOverhead=2g

这个公式不是绝对的，但作为起点很实用。具体还要根据作业的Shuffle量和数据量调整。

作业不开始跑先看YARN UI，确认是资源不够还是队列问题。生产环境用cluster模式。资源配置用“5核+13G”的经验公式作为起点。面试时能说清楚排查流程 + 资源参数 + cluster vs client的区别和踩坑，就很完整。

第1-5篇完结。下一辑继续聊Shuffle原理与优化、cache()和persist()的正确用法、Catalyst优化器、AQE自适应查询执行、Spark容错机制等实战场景。

你们生产环境的Spark资源怎么配的？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长

刷题进度保存在当前浏览器