EMR 5.13：Spark 2.3.0 UI显示Executor持续存活问题咨询

嘿，这个问题我之前在维护EMR集群时碰到过类似的情况，咱们一步步拆解来看——这不一定单纯是UI故障，得结合实际运行状态排查：

这是最关键的第一步，别上来就认定是UI问题：

• 用YARN命令查实际容器状态：
  先找你的Spark应用ID：yarn application -list -appStates ALL
  再查该应用的容器状态：yarn container -list -appId <你的应用ID>
  如果所有容器都显示FINISHED，那基本可以确定是UI层面的显示问题。
• 直接登到集群节点上看进程：
  执行ps aux | grep spark-executor，如果找不到对应的进程，那肯定是UI的锅。

EMR 5.13搭配的是Spark 2.3.0，这个版本确实有一些已知的Executor回收问题：

• 动态分配配置异常：如果开启了spark.dynamicAllocation.enabled，但spark.dynamicAllocation.executorIdleTimeout设置得太长，或者资源调度器的回收逻辑出了问题，会导致Executor在任务完成后一直挂着。默认超时是60秒，你可以检查下自己的配置有没有被修改。
• 资源未正确关闭：如果你的应用代码里有未关闭的数据库连接、文件句柄、或者自定义的线程池，会阻塞Spark的shutdown hook执行，导致Executor无法正常退出。去YARN的ApplicationMaster日志或者Executor日志里搜搜有没有“shutdown hook blocked”之类的报错。
• EMR 5.13的版本bug：这个版本的Spark和YARN集成确实存在一些边缘场景的问题，比如某些类型的任务完成后，Executor的回收逻辑失效，后续的EMR版本（比如5.20及以上）已经修复了不少这类问题。

• Spark History Server缓存问题：Spark历史服务器会缓存应用状态，有时候缓存更新不及时就会出现这种滞后显示。你可以重启Spark History Server服务，或者清理它的存储目录（默认是/var/log/spark/apps），之后再刷新UI看看。
• EMR控制台的同步延迟：EMR的UI是聚合了YARN、Ganglia、Spark的数据，偶尔会出现组件间状态同步不及时的情况，但1小时的延迟确实异常，大概率是EMR 5.13的UI组件bug，升级EMR版本能解决这类问题。

1. 先通过命令行和节点进程确认Executor的真实状态，别被UI误导；
2. 如果是UI问题：重启Spark History Server，清理缓存，不行就考虑升级EMR版本；
3. 如果是Executor真的没退出：检查代码里的资源关闭逻辑，核对动态分配配置，查看日志找shutdown相关的阻塞点。

内容的提问来源于stack exchange，提问作者y2k-shubham