紗殺死執行人的saveAsNewApihadoopFile

Question

期間超過內存限制

我目前正在批量加載數據到HBase的從Spark和我主要與以下示例工作：

http://www.opencore.com/blog/2016/10/efficient-bulk-load-of-hbase-using-spark/ http://zeyuanxy.github.io/hbase_bulk_loading/

但是我的聚集數據在一開始就比較複雜一點。

源文件大約40GB的AVRO具有相當數量（可能爲空）的字段（> 200）的記錄。我的整個事情都經過了，但是在saveAsNewApihadoopFile容器開始因超過內存限制而死亡。我嘗試了更多數量的分區（最多4000個），但是當我給執行程序更多的內存（每個4 GB）時，仍然會收到容器失敗的問題。另外我得到非常高的GC時間，然後反過來使整個事情變得非常緩慢。

這裏有一些問題：

有誰知道我如何能夠進一步配置文件中的工作，找出究竟爲什麼執行人需要這麼多的內存？或者我能做些什麼來減輕它呢？

在調用saveAsNewApihadoopFile來縮小問題範圍並避免不必要的數據重新分配（我的工作流程的一部分是repartitionAndSortWithinPartition）之前，是否需要先執行一個操作？

謝謝！

Answer 1

首先，您可以嘗試調整spark.yarn.executor.memoryOverhead和「內存分數」相關的設置。

關於剖析，有取決於你如何接近得到實際的節點和他們的JVM和日誌幾個選項：

• 如果有可能，儘量在執行人的JVM支持JMX，並連接到任何的他們用像VisualVM這樣的工具可以看到實際的統計數據。
• 如果訪問權限有限，您可以從執行器JVM執行或請求內存轉儲。
• 而最後一招 - 通過spark.executor.extraJavaOptions啓用內存概要分析，並與旁邊的選項進行調整（檢查它們是否適合GC您選擇）：

-XX:+UnlockDiagnosticVMOptions -XX:+PrintGCDetails -XX:+PrintFlagsFinal -XX:+PrintReferenceGC -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy -XX:+G1SummarizeConcMark 這樣你就能有診斷輸出在執行者記錄。