我想知道是否有人有一种神奇的方法来避免Spark日志中的此类消息:
2015-08-30 19:30:44 ERROR LiveListenerBus:75 - SparkListenerBus has already
stopped! Dropping event SparkListenerExecutorMetricsUpdate(41,WrappedArray())
Run Code Online (Sandbox Code Playgroud)
经过进一步调查,据我所知,LiveListenerBus延伸AsynchronousListenerBus.因此,在某些时候,.stop()方法被称为.然后,可能会发送/接收的消息将被丢弃并保持未处理状态.基本上,SparkListenerExecutorMetricsUpdate遗憾的是,有些消息尚未收到,一旦它们出现,它们就会被丢弃.
这看起来并不重要,因为SparkListenerExecutorMetricsUpdate它只对应于执行程序的Periodic更新.
令人尴尬的是,我绝对不明白为什么会发生这种情况而且没有提到这个问题.请注意,这是完全不确定的,我无法重现这一点,可能是由于异步性质以及我对如何/何时stop()应该被调用缺乏了解.
紧凑的样本:
val sc = new SparkContext(sparkConf)
val metricsMap = Metrics.values.toSeq.map(
v => v -> sc.accumulator(0, v.toString)
).toMap
val outFiles = sc.textFile(outPaths)
Run Code Online (Sandbox Code Playgroud)
并且没有其他参考sc或SparkContent实例.
这张票可能是相关的。 https://issues.apache.org/jira/browse/SPARK-12009
该消息似乎表明 SparkContext 停止后纱线分配失败。
抱歉评论不清楚。
主要原因似乎是AM的关闭事件和执行器停止所有之间有一些间隔。
因此,AM 尝试在执行程序停止后重新分配。
正如赛赛下面所说,
有趣的是,AM 在 2015-11-26,03:05:16 关闭,但是 YarnAllocator 在 11 秒后仍然请求 13 个执行器。看起来 AM 退出的速度并不快,这就是为什么 YarnAllocator 仍在请求新容器。通常情况下,如果 AM 在收到断开连接消息后立即退出,则容器将没有时间请求 YarnAllocator。
有时我在接近完成 Spark 上下文时遇到过类似的日志。
就我而言,这张票似乎就是答案。
| 归档时间: |
|
| 查看次数: |
20395 次 |
| 最近记录: |