在saveAsNewApihadoopFile期间，Yarn杀死Executors超出内存限制

Question

我目前正在尝试从Spark批量加载数据到HBase，主要使用以下示例：

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

然而，我在开始时对数据的聚合比较复杂。

源文件大约是40GB的AVRO Records，具有相当数量（可能为空）的字段（> 200）。我的整个事情贯穿但在saveAsNewApihadoopFile容器开始因超出内存限制而被杀死。我已经尝试了更多的分区（最多4000个），但是当我给执行程序更多的内存（每个4 GB）时，我仍然得到容器失败。此外，我获得了非常高的GC时间，这反过来又使整个事情变得非常缓慢。

以下是一些问题：

有谁知道如何进一步分析这份工作，找出执行者为什么需要这么多内存？或者我可以做些什么来减轻它？

我是否需要在调用saveAsNewApihadoopFile之前先执行操作以缩小问题范围，并避免不必要的数据重新分配（我的工作流程的一部分是repartitionAndSortWithinPartition）？

谢谢！

Answer 1

首先，您可以尝试调整spark.yarn.executor.memoryOverhead和＆＃34;内存分数＆＃34;相关设置。

关于性能分析，几乎没有选项取决于您可以获得实际节点及其jvms和日志的距离：

• 如果可能，尝试在执行程序JVM上启用JMX，并使用VisualVM等工具连接到其中任何一个，以便能够查看实际的统计信息。
• 如果访问受限，您可以执行或请求执行程序JVM进行内存转储。
• 最后的手段 - 通过spark.executor.extraJavaOptions启用内存分析，并使用下一个选项进行调整（检查它们是否适合您选择的GC）：

-XX:+UnlockDiagnosticVMOptions -XX:+PrintGCDetails -XX:+PrintFlagsFinal -XX:+PrintReferenceGC -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy -XX:+G1SummarizeConcMark 这样您就可以在执行程序日志中获得诊断输出。