Question

我们在AWS EMR上运行Spark Streaming作业。此作业将在10到14小时之间稳定运行，然后在stderr，stdout或Cloudwatch日志中没有可识别的错误而崩溃。在此次崩溃之后，任何重新启动作业的尝试都将立即失败并显示“'无法分配内存'（错误号= 12）”（full message）。

使用Cloudwatch指标和Ganglia进行的调查表明，driver.jvm.heap.used随着时间的推移正在稳步增长。

这两个观察结果让我相信Spark的一些长期运行组件（即高于Job-level）无法正确释放内存。重新启动hadoop-yarn-resourcemanager（根据here）会导致堆使用率降至“新集群”级别，这一点得到了支持。

如果我的假设确实是正确的 - 什么会导致纱线继续消耗越来越多的记忆？（如果不是 - 我怎么能伪造那个？）

我从here看到spark.streaming.unpersist默认为true（尽管我在工作结束时尝试添加手册rdd.unpersist()只是为了检查是否有任何影响 - 它的运行时间还不够明确，但是）
Here，对spark.yarn.am.extraJavaOptions的评论表明，当以纱线客户端模式（我们是）运行时，spark.yarn.am.memory设置最大Yarn应用程序管理器堆内存使用量。我们的工作中不会覆盖此值（因此默认值为512m），但Cloudwatch和Ganglia都清楚地显示了千兆字节中的驱动程序堆使用情况。

Answer 1

事实证明，默认的SparkUI值here比我们的系统可以处理的要大得多。将它们设置为默认值的1/20后，系统已稳定运行24小时，并且在此期间堆使用量没有增加。

为清楚起见，编辑的值为：

* 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

纱线堆使用量随时间增长

1 个答案: