我想知道是否有人有一种神奇的方法来避免Spark日志中的此类消息:
2015-08-30 19:30:44 ERROR LiveListenerBus:75 - SparkListenerBus has already
stopped! Dropping event SparkListenerExecutorMetricsUpdate(41,WrappedArray())
经过进一步调查,我了解到LiveListenerBus
延伸AsynchronousListenerBus
。因此,在某些时候,调用.stop()
方法。然后,可能会发送/接收的消息将被丢弃并保持未处理状态。基本上,遗憾的是,一些SparkListenerExecutorMetricsUpdate
消息尚未收到,一旦它们出现,它们就会被丢弃。
这并不重要,因为SparkListenerExecutorMetricsUpdate
只对应于来自执行者的定期更新。
令人尴尬的是,我绝对不明白为什么会发生这种情况,并且没有提到这个问题。请注意,这是完全不确定的,我无法重现这一点,可能是由于异步性质以及我对如何/何时应该调用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)
并且没有其他人提及sc
或SparkContent
个实例。
答案 0 :(得分:3)
这张票可能是相关的。 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。
我有时会在完成火花环境附近遇到类似的日志 在我的情况下,这张票似乎是答案。