Spark程序運行常見錯誤解決方法以及優(yōu)化是怎樣的

Spark程序運行常見錯誤解決方法以及優(yōu)化是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

一.org.apache.spark.shuffle.FetchFailedException

1.問題描述

這種問題一般發(fā)生在有大量shuffle操作的時候,task不斷的failed,然后又重執(zhí)行，一直循環(huán)下去，非常的耗時。

2.報錯提示

(1) missing output location

org.apache.spark.shuffle.MetadataFetchFailedException: Missing an output location for shuffle 0

(2) shuffle fetch faild

org.apache.spark.shuffle.FetchFailedException: Failed to connect to spark047215/192.168.47.215:50268

當(dāng)前的配置為每個executor使用1cpu,5GRAM,啟動了20個executor

3.解決方案

一般遇到這種問題提高executor內(nèi)存即可,同時增加每個executor的cpu,這樣不會減少task并行度。

• spark.executor.memory 15G

• spark.executor.cores 3

• spark.cores.max 21

啟動的execuote數(shù)量為:7個

execuoteNum = spark.cores.max/spark.executor.cores

每個executor的配置：

3core,15G RAM

消耗的內(nèi)存資源為:105G RAM

15G*7=105G

可以發(fā)現(xiàn)使用的資源并沒有提升，但是同樣的任務(wù)原來的配置跑幾個小時還在卡著，改了配置后幾分鐘就結(jié)束了。

二.Executor&Task Lost

1.問題描述

因為網(wǎng)絡(luò)或者gc的原因,worker或executor沒有接收到executor或task的心跳反饋

2.報錯提示

(1) executor lost

WARN TaskSetManager: Lost task 1.0 in stage 0.0 (TID 1, aa.local): ExecutorLostFailure (executor lost)

(2) task lost

WARN TaskSetManager: Lost task 69.2 in stage 7.0 (TID 1145, 192.168.47.217): java.io.IOException: Connection from /192.168.47.217:55483 closed

(3) 各種timeout

java.util.concurrent.TimeoutException: Futures timed out after [120 second

ERROR TransportChannelHandler: Connection to /192.168.47.212:35409 has been quiet for 120000 ms while there are outstanding requests. Assuming connection is dead; please adjust spark.network.timeout if this is wrong

3.解決方案

提高 spark.network.timeout 的值，根據(jù)情況改成300(5min)或更高。

默認為 120(120s),配置所有網(wǎng)絡(luò)傳輸?shù)难訒r，如果沒有主動設(shè)置以下參數(shù)，默認覆蓋其屬性

• spark.core.connection.ack.wait.timeout

• spark.akka.timeout

• spark.storage.blockManagerSlaveTimeoutMs

• spark.shuffle.io.connectionTimeout

• spark.rpc.askTimeout or spark.rpc.lookupTimeout

三.傾斜

1.問題描述

大多數(shù)任務(wù)都完成了，還有那么一兩個任務(wù)怎么都跑不完或者跑的很慢。

分為數(shù)據(jù)傾斜和task傾斜兩種。

2.錯誤提示

(1) 數(shù)據(jù)傾斜

(2) 任務(wù)傾斜

差距不大的幾個task,有的運行速度特別慢。

3.解決方案

(1) 數(shù)據(jù)傾斜

數(shù)據(jù)傾斜大多數(shù)情況是由于大量null值或者""引起，在計算前過濾掉這些數(shù)據(jù)既可。

例如：

sqlContext.sql("...where col is not null and col != ''")

(2) 任務(wù)傾斜

task傾斜原因比較多，網(wǎng)絡(luò)io,cpu,mem都有可能造成這個節(jié)點上的任務(wù)執(zhí)行緩慢，可以去看該節(jié)點的性能監(jiān)控來分析原因。以前遇到過同事在spark的一臺worker上跑R的任務(wù)導(dǎo)致該節(jié)點spark  task運行緩慢。

或者可以開啟spark的推測機制，開啟推測機制后如果某一臺機器的幾個task特別慢，推測機制會將任務(wù)分配到其他機器執(zhí)行，***Spark會選取最快的作為最終結(jié)果。

spark.speculation true

spark.speculation.interval 100 - 檢測周期，單位毫秒;

spark.speculation.quantile 0.75 - 完成task的百分比時啟動推測

spark.speculation.multiplier 1.5 - 比其他的慢多少倍時啟動推測。

四.OOM(內(nèi)存溢出)

1.問題描述

內(nèi)存不夠，數(shù)據(jù)太多就會拋出OOM的Exeception

因為報錯提示很明顯，這里就不給報錯提示了。。。

2.解決方案

主要有driver OOM和executor OOM兩種

(1) driver OOM

一般是使用了collect操作將所有executor的數(shù)據(jù)聚合到driver導(dǎo)致。盡量不要使用collect操作即可。

(2) executor OOM

1.可以按下面的內(nèi)存優(yōu)化的方法增加code使用內(nèi)存空間

2.增加executor內(nèi)存總量,也就是說增加spark.executor.memory的值

3.增加任務(wù)并行度(大任務(wù)就被分成小任務(wù)了)，參考下面優(yōu)化并行度的方法

優(yōu)化

1.內(nèi)存

當(dāng)然如果你的任務(wù)shuffle量特別大，同時rdd緩存比較少可以更改下面的參數(shù)進一步提高任務(wù)運行速度。

spark.storage.memoryFraction - 分配給rdd緩存的比例，默認為0.6(60%)，如果緩存的數(shù)據(jù)較少可以降低該值。

spark.shuffle.memoryFraction - 分配給shuffle數(shù)據(jù)的內(nèi)存比例，默認為0.2(20%)

剩下的20%內(nèi)存空間則是分配給代碼生成對象等。

如果任務(wù)運行緩慢，jvm進行頻繁gc或者內(nèi)存空間不足，或者可以降低上述的兩個值。

"spark.rdd.compress","true" - 默認為false，壓縮序列化的RDD分區(qū),消耗一些cpu減少空間的使用

如果數(shù)據(jù)只使用一次，不要采用cache操作，因為并不會提高運行速度，還會造成內(nèi)存浪費。

2.并行度

spark.default.parallelism

發(fā)生shuffle時的并行度，在standalone模式下的數(shù)量默認為core的個數(shù)，也可手動調(diào)整，數(shù)量設(shè)置太大會造成很多小任務(wù)，增加啟動任務(wù)的開銷，太小，運行大數(shù)據(jù)量的任務(wù)時速度緩慢。

spark.sql.shuffle.partitions

sql聚合操作(發(fā)生shuffle)時的并行度，默認為200,如果任務(wù)運行緩慢增加這個值。

相同的兩個任務(wù)：

spark.sql.shuffle.partitions=300:

spark.sql.shuffle.partitions=500:

速度變快主要是大量的減少了gc的時間。

修改map階段并行度主要是在代碼中使用rdd.repartition(partitionNum)來操作。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。