scala - MapPartitions 上的垃圾收集问题

Question

我目前有一个 mapPartitions 作业，它是 flatMapping 中的每个值迭代器，我遇到了一个问题，其中会产生主要的 GC 成本在某些处决上。一些执行者需要 20 分钟，其中 15 分钟是纯粹的垃圾收集，我相信其中很大一部分与我正在输出的 ArrayBuffer。有没有人有任何建议如何我可以做某种形式的流输出吗？

此外，对于跟踪/解决 GC，有没有人有一般的建议？ Spark 中的问题？

Answer 1

请引用Spark调优官方页面的以下文档。我希望它至少能帮助你的分析指明方向:

内存管理概述Spark 中的内存使用主要属于两类之一:执行和存储。执行内存是指用于洗牌、连接、排序和聚合中的计算，而存储内存是指用于在集群中缓存和传播内部数据的内存。在 Spark 中，执行和存储共享一个统一的区域(M)。当没有使用执行内存时，存储可以获得所有可用内存，反之亦然。如有必要，执行可能会逐出存储，但只有在总存储内存使用量低于某个阈值 (R) 时才会执行。换句话说，R 描述了 M 中的一个子区域，其中缓存 block 永远不会被驱逐。由于实现的复杂性，存储可能不会驱逐执行。

这种设计确保了几个理想的特性。首先，不使用缓存的应用程序可以使用整个空间来执行，避免不必要的磁盘溢出。其次，确实使用缓存的应用程序可以保留最小存储空间 (R)，使它们的数据 block 不会被逐出。最后，这种方法为各种工作负载提供合理的开箱即用性能，而无需用户了解内部内存划分方式。

虽然有两个相关配置，但一般用户不需要调整它们，因为默认值适用于大多数工作负载:

spark.memory.fraction 将 M 的大小表示为(JVM 堆空间 - 300MB)的分数(默认为 0.6)。其余空间 (40%) 保留用于用户数据结构、Spark 中的内部元数据，以及在稀疏和异常大的记录情况下防止 OOM 错误。spark.memory.storageFraction 将 R 的大小表示为 M 的分数(默认为 0.5)。 R 是 M 中的存储空间，其中缓存 block 不受执行驱逐的影响。应该设置 spark.memory.fraction 的值，以便在 JVM 的旧代或“终身”代中舒适地适应这个堆空间量。有关详细信息，请参阅下面关于高级 GC 调优的讨论。