Spark UI 对应用程序内存使用有什么影响？

Question

我有一个 Spark 应用程序 (2.4.5)，使用 Kafka 作为使用大批处理窗口（5 分钟）的源，在我们的应用程序中，我们只真正关心该特定间隔的 RDD 来处理数据。

发生的情况是，我们的应用程序时常崩溃，要么是驱动程序上出现 OutOfMemory 异常（在客户端模式下运行），要么是执行程序上出现 GC OutOfMemory。经过大量研究后，我们似乎没有正确处理状态，导致血统无限增长。我们考虑通过使用批处理方法来解决该问题，在该方法中，我们控制从 Kafka 获取的偏移量并从中创建 RDD（这将截断沿袭），或者启用检查点。

在调查过程中，有人发现了一个不太相似的问题，通过调整一些 UI 参数解决了这个问题（Yarn Heap 使用量随着时间的推移而增长）：

• Spark.ui.retainedJobs=50
• Spark.ui.retainedStages=50
• Spark.ui.retainedTasks=500
• Spark.worker.ui.retainedExecutors=50
• Spark.worker.ui.retainedDrivers=50
• Spark.sql.ui.retainedExecutions=50
• Spark.streaming.ui.retainedBatches=50

由于这些是 UI 参数，因此它们会影响应用程序的内存使用情况对我来说没有意义，除非它们影响应用程序存储发送到 UI 的信息的方式。早期测试表明，应用程序确实运行时间更长，没有出现 OOM 问题。

谁能解释一下这些参数对应用程序有什么影响？它们真的会影响应用程序的内存使用吗？我是否应该研究任何其他参数来了解整个情况（我想知道是否有一个“因素”参数需要调整，以便内存分配适合我们的情况）？

谢谢

Answer 1

经过大量测试后，我们的团队设法将问题范围缩小到这个特定参数：

Spark.sql.ui.retainedExecutions

我决定深入研究，所以我下载了 Spark 的代码。我发现有关解析逻辑计划的信息不仅保存在应用程序的内存中，而且还受此参数控制。

创建 SparkSession 会话时，实例化的众多对象之一是 SQLAppStatusListener。该类实现了两个方法：

onExecutionStart - 在每次执行时，创建一个新的 SparkPlanGraphWrapper，它将保存对已解析逻辑计划的引用，并将其添加到 SharedState 对象中，在本例中，该对象跟踪创建了多少个对象实例。

cleanupExecution -如果存储的对象数量大于 Spark.sql.ui.retainedExecutions 的值（默认为1000），则从 SharedState 对象中删除 SparkPlanGraphWrapper 。

具体来说，在我们的例子中，逻辑计划占用 4MB 内存，因此简单地说，我们必须分配 4GB 内存来容纳保留的执行。