混乱阶段的内存错误(丢失任务.)用Pregel算法处理一个很大的图时

Question

我正在Scala..中用火花GraphX执行Pregel算法。

我的图表包含一百万个节点，它们之间有五百万个边。我的集群非常强大，有几台用于BigData的服务器，每个服务器都有256 My的内存。

我有一个"Java错误“在洗牌阶段，在执行过程中，经过超过20分钟的处理：任务丢失了.我将分析这些参数：

• I加载图的方式及其持久性(StorageLevel)分析
• 内存的分析：节点、边缘和发送的消息
• 分析火花提交命令时星火中设置的参数：执行器的数量，每个执行器的，serialization...

Answer 1

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

• 参数的火花用于火花提交：90%使用可用纱线内存在集群中。我在每个物理服务器上使用3 vcore/executor和3执行器。我使用KryoSerializer运行它，以减少存储的数据空间。
• 图-节点和边的RDDs：以前，我使用合并方法在HDFS中创建并存储节点和边缘的RDDs，使数据保存一致，虽然保存时间很长。
• 图形加载:从HDFS中现有的RDD文件中加载。
• 图-节点和边：正确加载.它们在scala中的属性仅是我使用的属性(每个属性5个)，内存使用最少(整数)，没有辅助属性。
• Graph 合并到mergeMsg方法中:我使用自己的公式(与项目的目标相关)组合这2条消息。
• Graph：节点收集消息中收到的所有信息，并将其保存在每个节点内的“已知良好信息”列表中。该信息用于创建
• Graph 在sendMsg方法中发送:每个节点使用其info (已知的好信息列表及其其他属性)来创建要发送的消息。另外，为了减少消息的数量，我过滤了一些无用的消息，以便不将它们发送到Iterator中。

我发现了我的主要问题：保存“已知好信息”的每个节点中的List是不变的。

解决方案:我应该使用ListBuffer (可变的)。另外，我应该使用.append()方法，而不是.++()方法，因为这个方法创建了列表的一个新实例。

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

现在的性能比现在快10倍多，内存错误也不会出现。