Spark應用程序終止執行程序

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

另外，我在火花日誌中發現了一些奇怪的條目（與stage執行開始時相同）。

站長：

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)

沒有與因爲工人，主站（以上日誌）的網絡連接，驅動程序中的同一計算機上運行也沒有問題。

星火版本1.6.1

來源

2016-12-01 Cortwave

您能添加導致故障的工作人員的日誌嗎？任務失敗次數可能導致工人死亡。有沒有例外發生？ –

@YuvalItzchakov工作人員從丟失執行者的工人登錄工作日誌。在遺囑執行人失蹤之前，沒有任何例外和失敗。 – Cortwave

*「工人登錄工人失去執行人員的職位」*不確定這是什麼意思 –

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

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

退出137強烈建議的資源問題，內存或CPU內核。鑑於您可以通過重新運行階段來解決您的問題，它可能會以某種方式將所有核心分配給您（也許您還有一些Spark shell正在運行？）。這是獨立Spark設置（一臺主機上的所有內容）的常見問題。

無論哪種方式，我會嘗試下面的事情依次是：

提高存儲內存派spark.storage.memoryFraction預先分配存儲更多的內存和防止系統OOM殺手隨機給你137在一個大階段。
爲應用程序設置較少的內核數量，以排除在舞臺運行之前預先分配這些內核的情況。你可以通過spark.deploy.defaultCores來做到這一點，將其設置爲3或甚至2（在intel四核上假設有8個核心）
Outright爲Spark分配更多RAM - >spark.executor.memory需要增加。
也許你碰上與元數據清除的問題在這裏，也沒有聽說過在當地的部署，在這種情況下添加
export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200"到最後你spark-env.sh可能被強制元數據清除，以更頻繁地運行

其中一個應該做的伎倆在我看來。

來源

2016-12-21 22:18:23

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

同樣的問題就走了，當我增加了參數：28（這是執行者，我不得不數）至84（這是可用的內核數）

spark.default.parallelism。

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

UPDATE：這種做法也被Spark's documentation支持：

有時候，你會得到一個OutOfMemoryError不是因爲你的RDDS不裝入內存，但由於工作集的任務之一，比如groupByKey中的一個reduce任務，太大了。 Spark的shuffle操作（sortByKey，groupByKey，reduceByKey，join等）在每個任務中構建一個哈希表來執行分組，這通常很大。 這裏最簡單的解決方法是增加並行度，以便每個任務的輸入集更小。 Spark可以有效地支持短至200毫秒的任務，因爲它可以跨多個任務重用一個執行器JVM，並且任務啓動成本較低，因此您可以安全地將並行度提高到超過集羣內核數量。

來源

2017-03-09 15:40:10 vefthym

你對此有一些理論上的解釋嗎？ – Cortwave

@Cortwave是的，增加分區數減少了每個任務的內存需求（每個分區由一個任務處理）。至於具體的數字，沒有，但在我以前的MapReduce體驗中，添加更多的分區具有相同的行爲，我一直在增加它們，直到沒有引發OOM錯誤（如果適用）。 – vefthym

Spark應用程序終止執行程序

回答

相關問題