Spark應用程序殺死執行程序

Question

我在獨立模式下運行spark集群，使用spark-submit運行應用程序。 在火花UI階段我發現執行階段有大的執行時間（> 10h，通常時間~30秒）。 階段有許多失敗的任務，錯誤Resubmitted (resubmitted due to lost executor) 。 在階段頁面中Aggregated Metrics by Executor部分的Aggregated Metrics by Executor有地址執行者CANNOT FIND ADDRESS 。 Spark試圖無限地重新提交此任務。 如果我殺了這個階段（我的應用程序自動重新運行未完成的火花作業），所有都繼續正常工作。

此外，我在spark日志中發現了一些奇怪的條目（與階段執行開始同時）。

主：

16/11/19 19:04:32 INFO Master: Application app-20161109161724-0045 requests to kill executors: 0
16/11/19 19:04:36 INFO Master: Launching executor app-20161109161724-0045/1 on worker worker-20161108150133
16/11/19 19:05:03 WARN Master: Got status update for unknown executor app-20161109161724-0045/0
16/11/25 10:05:46 INFO Master: Application app-20161109161724-0045 requests to kill executors: 1
16/11/25 10:05:48 INFO Master: Launching executor app-20161109161724-0045/2 on worker worker-20161108150133
16/11/25 10:06:14 WARN Master: Got status update for unknown executor app-20161109161724-0045/1

工人：

16/11/25 10:06:05 INFO Worker: Asked to kill executor app-20161109161724-0045/1
16/11/25 10:06:08 INFO ExecutorRunner: Runner thread for executor app-20161109161724-0045/1 interrupted
16/11/25 10:06:08 INFO ExecutorRunner: Killing process!
16/11/25 10:06:13 INFO Worker: Executor app-20161109161724-0045/1 finished with state KILLED exitStatus 137
16/11/25 10:06:14 INFO Worker: Asked to launch executor app-20161109161724-0045/2 for app.jar
16/11/25 10:06:17 INFO SecurityManager: Changing view acls to: spark
16/11/25 10:06:17 INFO SecurityManager: Changing modify acls to: spark
16/11/25 10:06:17 INFO SecurityManager: SecurityManager: authentication disabled; ui acls disabled; users with view permissions: Set(spark); users with modify permissions: Set(spark)

網絡連接沒有問題，因為worker，master（上面的日志），驅動程序在同一台機器上運行。

Spark 1.6.1版

Answer 1

可能日志中有趣的部分是這樣的：

16/11/25 10:06:13 INFO Worker: Executor app-20161109161724-0045/1 finished with state KILLED exitStatus 137

退出137強烈建議資源問題，內存或CPU內核。 鑒於您可以通過重新運行階段來解決問題，可能是某些核心已經分配（也許您還運行了一些Spark shell？）。 這是獨立Spark設置的常見問題（一台主機上的所有內容）。

無論哪種方式，我都會按順序嘗試以下事項：

1. 提高存儲內存派系spark.storage.memoryFraction以預先分配更多內存用於存儲，並防止系統OOM殺手在大舞台上隨機提供137 。
2. 為應用程序設置較少數量的核心，以排除在運行階段之前預先分配這些核心的內容。 您可以通過spark.deploy.defaultCores執行此spark.deploy.defaultCores ，將其設置為3或甚至2（在假設8個vcores的intel四核上）
3. Outright為Spark分配更多內存 - > spark.executor.memory需要上升。
4. 也許你在這里遇到了元數據清理的問題，在本地部署中也沒有聞所未聞，在這種情況下添加
   export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200"到最后你的spark-env.sh可以通過強制元數據清理更頻繁地運行來解決這個問題

在我看來，其中一個應該成功。

Answer 2

阿明的答案非常好。 我只想指出對我有用的東西。

當我增加參數時，同樣的問題就消失了：

spark.default.parallelism從28（這是我擁有的執行程序的數量）到84（這是可用核心的數量）。

注意：這不是設置此參數的規則，這只適用於我。

更新 ：此方法也得到Spark的文檔支持：

有時候，你會得到一個OutOfMemoryError，不是因為你的RDD不適合內存，而是因為你的一個任務的工作集，例如groupByKey中的一個reduce任務，太大了。 Spark的shuffle操作（sortByKey，groupByKey，reduceByKey，join等）在每個任務中構建一個哈希表來執行分組，這通常很大。 這里最簡單的解決方法是增加並行度，以便每個任務的輸入集更小。 Spark可以有效地支持短至200毫秒的任務，因為它在許多任務中重用了一個執行程序JVM，並且它具有較低的任務啟動成本，因此您可以安全地將並行度提高到超過群集中的核心數。