使用Pregel算法处理非常大的图时，随机阶段（丢失任务...）中的内存错误

Question

我正在使用Scala中的Spark GraphX执行 Pregel算法。

我的图表包含100万个节点，以及它们之间的5毫米边。 我的集群非常强大，有几个BigData服务器，每个服务器有256GB内存。

我有一个＆＃34; Java堆空间错误＆＃34;在执行过程中处于洗牌阶段，处理超过20分钟后：任务丢失 ... 我将分析这些参数：

• 分析我加载图表的方式及其持久性（StorageLevel）
• 分析内存使用者：发送的节点，边缘和消息
• 使用spark-submit命令时在Spark中设置的参数分析：每个执行程序的执行程序，内存/ vcores 的数量，序列化 ...

Answer 1

我的分析结论和我使用的优化：

• spark-submit 中使用的Spark参数： 90％可用YARN 内存在群集中。我使用 3个vcores / executor 和每个物理服务器3个执行器。我用KryoSerializer运行它，以减少存储数据的空间。

• 图表 - 节点和边缘的RDD：之前，我使用coalesce在1000个文件中创建并存储了 HDFS 中的节点和边缘的RDD，这样可以统一保存数据，但会持续很长时间。

• 图表 - 正在加载：来自HDFS中的现有RDD文件。

• 图表 - 节点和边缘：正确加载。它们在scala中的属性只是我使用的属性（每个属性有5个属性），内存使用最少（整数），没有辅助属性。

图表 - 消息在 mergeMsg 方法中合并：我使用自己的公式（与项目目标相关）合并了2条消息。

• 图表 - vprog：节点收集邮件中收到的所有信息，并将其保存在＆＃34;已知良好信息列表中。在每个节点内。该信息用于创建

在 sendMsg 方法中发送的

• 图表 - 消息：每个节点使用其信息（已知正确信息列表及其他属性）来创建要发送的消息发送。另外，为了减少消息数量，我过滤了无用的消息，以免在迭代器中发送消息。

我发现了我的主要问题：每个节点内的列表，用于保存＆＃34;已知的良好信息＆＃34; 不可变。

解决方案：我应该使用ListBuffer（可变）。另外，我应该使用方法 .append（）而不是。++（），因为这个创建了List的新实例。

scala中的集合的更多信息：http://docs.scala-lang.org/overviews/collections/performance-characteristics

现在性能提高了10倍以上，并且现在没有出现内存错误。