纱杀死执行人的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 这样你就能有诊断输出在执行者记录。