由于地方等级而导致的严重拖延任务是＆＃34;任何＆＃34;和缓存的RDD上的网络抓取

Question

正在重新处理已成功完全读取的缓存数据集。在相同（仍然缓存）的数据集上的后续传递中，少量（通常为2/204任务 - 1％）任务可能会失败。我们正处于火花1.3.1。

以下屏幕截图显示 - 在204个任务中 - 最后两个似乎已被遗忘＆＃39;由调度程序。

有没有办法获得有关这些任务的更多信息？

所有其他任务在相似时间的合理分数内完成：特别是75％仍然在中位数的50％之内。正是这最后两个落后者正在杀死整个工作完成时间。另请注意，这些不是由于记录计数偏差

更新两位落后者终于完成了 - 超过7分钟（超过任何其他202项任务的3倍）！

15/08/15 20:04:54 INFO TaskSetManager: Finished task 201.0 in stage 2.0 (TID 601) in 133583 ms on x125 (202/204)

15/08/15 20:09:53 INFO TaskSetManager: Finished task 189.0 in stage 2.0 (TID 610) in 423230 ms on i386 (203/204)
15/08/15 20:10:05 INFO TaskSetManager: Finished task 190.0 in stage 2.0 (TID 611) in 435459 ms on i386 (204/204)
15/08/15 20:10:05 INFO DAGScheduler: Stage 2 (countByKey at MikeFilters386.scala:76) finished in 599.028 s

有关寻找/审核的建议。

另一次更新这两种类型的TYPE已经证明是网络。这是什么意思？

Answer 1

我和你有类似的问题。尝试增加spark.locality.wait。

如果可行，以下内容可能适用于您： https://issues.apache.org/jira/browse/SPARK-13718#

** ADDED **

我发现一些有用的额外信息。

1. Spark总是最初将任务分配给包含相应缓存的RDD分区的执行程序。
2. 如果在地点超时as defined in the spark config下未接受任务，则它将按该顺序尝试NODE_LOCAL，RACK_LOCAL，ANY。
3. 无论缓存数据是否在本地可用（HDFS副本），Spark都将始终从包含缓存分区的节点获取缓存分区。它只会重新计算，如果执行程序崩溃，那么RDD不再被缓存。在许多情况下，这也会在原始的straggler节点上造成网络瓶颈。

Answer 2

您是否尝试过使用Spark推测（spark.speculation true）？ Spark将识别这些落后者并在另一个节点上重新启动。