2016-01-20 66 views
1

我使用Dataproc跑过来用火花外壳簇星火命令。我经常收到错误/警告消息,表明我失去了与执行者的联系。这些消息是这样的:谷歌Dataproc - 断开与执行人往往

[Stage 6:>               (0 + 2)/2]16/01/20 10:10:24 ERROR  org.apache.spark.scheduler.cluster.YarnScheduler: Lost executor 5 on spark-cluster-femibyte-w-0.c.gcebook-1039.internal: remote Rpc client disassociated 
16/01/20 10:10:24 WARN akka.remote.ReliableDeliverySupervisor: Association with remote system [akka.tcp://[email protected] femibyte-w-0.c.gcebook-1039.internal:60599] has failed, address is now gated for [5000] ms. Reason: [Disassociated] 
16/01/20 10:10:24 WARN org.apache.spark.scheduler.TaskSetManager: Lost task 0.2 in stage 6.0 (TID 17, spark-cluster-femibyte-w-0.c.gcebook-1039.internal): ExecutorLostFailure (executor 5 lost) 
16/01/20 10:10:24 WARN org.apache.spark.scheduler.TaskSetManager: Lost task 1.2 in stage 6.0 (TID 16, spark-cluster-femibyte-w-0.c.gcebook-1039.internal): ExecutorLostFailure (executor 5 lost) 

...

这里是另外一个例子:

20 10:51:43 ERROR org.apache.spark.scheduler.cluster.YarnScheduler: Lost executor 2 on spark-cluster-femibyte-w-1.c.gcebook-1039.internal: remote Rpc client disassociated 
16/01/20 10:51:43 WARN akka.remote.ReliableDeliverySupervisor: Association with remote system [akka.tcp://[email protected]:58745] has failed, address is now gated for [5000] ms. Reason: [Disassociated] 
16/01/20 10:51:43 WARN org.apache.spark.scheduler.TaskSetManager: Lost task 1.0 in stage 4.0 (TID 5, spark-cluster-femibyte-w-1.c.gcebook-1039.internal): ExecutorLostFailure (executor 2 lost) 
16/01/20 10:51:43 WARN org.apache.spark.scheduler.TaskSetManager: Lost task 0.0 in stage 4.0 (TID 4, spark-cluster-femibyte-w-1.c.gcebook-1039.internal): ExecutorLostFailure (executor 2 lost) 
16/01/20 10:51:43 WARN org.apache.spark.ExecutorAllocationManager: Attempted to mark unknown executor 2 idle 

这是正常的吗?有什么我可以做,以防止这一点?

+0

您需要检查与运行的执行人节点的主节点的网络连接。另外,当您收到此消息时,您的工作人员是否关机/停止工作,还是仍然启动并且错误仍显示出来? – Sumit

+0

如何检查?我在Google云端。 Dataproc应该为我处理这个问题吗? – femibyte

+0

这发生在长时间运行的任务中。 – femibyte

回答

3

如果工作本身并没有失败,与事实,你没有看到实际任务失败(至少据我可以从什么张贴在这个问题告诉)相关的其他传播的错误最可能是你”只是看到无害,但known to be spammy issue in core Spark;这里的关键是Spark动态分配在作业期间放弃使用不足的执行程序,并根据需要重新分配它们。他们最初未能抑制执行者失去的一部分,但我们已经测试确保它对实际工作没有不良影响。

这里的a googlegroups thread突出一些火花对成纱的行为细节。

要检查它是否是真的动态分配引起的消息,尝试运行:

spark-shell --conf spark.dynamicAllocation.enabled=false \ 
    --conf spark.executor.instances=99999 

或者,如果你通过gcloud beta dataproc jobs提交作业,则:

gcloud beta dataproc jobs submit spark \ 
    --properties spark.dynamicAllocation.enabled=false,spark.executor.instances=99999 

如果你真正看到的网络打嗝或其他Dataproc错误解除关联主/工人时,它不是利用侧OOM什么的,您可以直接[email protected]电子邮件的Dataproc团队; beta不会成为潜在破坏行为的借口(尽管我们当然希望去除在测试期间我们可能还没有发现的棘手的边缘案例错误)。

+0

感谢您的建议。我会试试看。 – femibyte