Spark常見問題匯總

spark master和spark worker掛掉application恢複問題

首先分5中情況：

1，spark master進程掛掉了

2，spark master在執行中掛掉了

3，spark worker提交任務前全部掛掉了

4，spark worker在執行application過程中掛掉了

5，spark worker在執行application過程中全部掛掉了

1，spark master進程掛掉了

提交不了application，所以不用考慮application恢複問題

2，spark master在執行中掛掉了

不影響application正常執行，因為執行過程在worker中完成，並直接由worker返回結果。

3，spark worker提交任務前全部掛掉了

報錯資訊如下，啟動woker後，application恢複正常。

17/01/04 19:31:13 WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources

4，spark worker在執行application過程中掛掉了

報錯資訊如下：

17/01/04 19:41:50 ERROR TaskSchedulerImpl: Lost executor 0 on 192.168.91.128: Remote RPC client disassociated. Likely due to containers exceeding thresholds, or network issues. Check driver logs for WARN messages.

移除RPC client，檢查DAG是否丟失關鍵路徑，如果丟失重新計算，如果lost ：0 ，從BlockManagerMaster刪除失敗的executor，重新分發失敗的executor到其他worker。

5，spark worker在執行application過程中全部掛掉了

報錯資訊如下，

17/01/04 19:34:16 ERROR TaskSchedulerImpl: Lost executor 1 on 192.168.91.128: Remote RPC client disassociated. Likely due to containers exceeding thresholds, or network issues. Check driver logs for WARN messages.

application進入停滯狀態，等待worker註冊。

啟動worker後：executor重新註冊

刪除不可用executor，並重新註冊。

CoarseGrainedSchedulerBackend$DriverEndpoint: Asked to remove non-existent executor 0

CoarseGrainedSchedulerBackend$DriverEndpoint: Registered executor NettyRpcEndpointRef(null) (192.168.91.128:55126) with ID 1

worker啟動後application恢複正常返回結果，但仍然報錯如下。（2.1.0以後版本修複此bug）。  

org.apache.spark.SparkException: Could not find CoarseGrainedScheduler

1、WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster uito ensure that workers are registered and have sufficient memory 當前的叢集的可用資源不能滿足應用程式所請求的資源。 資源分2類： cores 和 ram Core代表對執行可用的executor slots Ram代表每個Worker上被需要的空閑記憶體來運行你的Application。 解決方案： 應用不要請求多餘空閑可用資源的 關閉掉已經執行結束的Application     2、Application isn’t using all of the Cores: How to set the Cores used by a Spark App 設定每個App所能獲得的core 解決方案： spark-env.sh裡設定spark.deploy.defaultCores 或 spark.cores.max     3、Spark Executor OOM: How to set Memory Parameters on Spark OOM是記憶體裡堆的東西太多了 1、增加job的並行度，即增加job的partition數量，把大資料集切分成更小的資料，可以減少一次性load到記憶體中的資料量。InputFomart， getSplit來確定。   2、spark.storage.memoryFraction 管理executor中RDD和運行任務時的記憶體比例，如果shuffle比較小，只需要一點點shuffle memory，那麼就調大這個比例。預設是0.6。不能比老年代還要大。大了就是浪費。   3、spark.executor.memory如果還是不行，那麼就要加Executor的記憶體了，改完executor記憶體後，這個需要重啟。   4、Shark Server/ Long Running Application Metadata Cleanup Spark程式的中繼資料是會往記憶體中無限儲存的。spark.cleaner.ttl來防止OOM，主要出現在Spark Steaming和Shark Server裡。 export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200"   5、Class Not Found: Classpath Issues 問題1、缺少jar，不在classpath裡。 問題2、jar包衝突，同一個jar不同版本。   解決1： 將所有依賴jar都打入到一個fatJar包裡，然後手動設定依賴到指定每台機器的DIR。 val conf = new SparkConf().setAppName(appName).setJars(Seq(System.getProperty("user.dir") + "/target/scala-2.10/sparktest.jar"))   解決2： 把所需要的依賴jar包都放到default classpath裡，分發到各個worker node上。     關於效能最佳化： 第一個是sort-based shuffle。這個功能大大的減少了超大規模作業在shuffle方面的記憶體佔用量，使得我們可以用更多的記憶體去排序。 第二個是新的基於Netty的網路模組取代了原有的NIO網路模組。這個新的模組提高了網路傳輸的效能，並且脫離JVM的GC自己管理記憶體，降低了GC頻率。 第三個是一個獨立於Spark executor的external shuffle service。這樣子executor在GC的時候其他節點還可以通過這個service來抓取shuffle資料，所以網路傳輸本身不受到GC的影響。   過去一些的參賽系統軟體方面的處理都沒有能力達到硬體的瓶頸，甚至對硬體的利用率還不到10%。而這次我們的參賽系統在map期間用滿了3GB/s的硬碟頻寬，達到了這些虛擬機器上八塊SSD的瓶頸，在reduce期間網路利用率到了1.1GB/s，接近物理極限。