我们在aws emr上运行spark流媒体作业。此作业将稳定运行10到14个小时，然后崩溃，stderr、stdout或cloudwatch日志中没有明显的错误。在此崩溃之后，任何重新启动作业的尝试都将立即失败，并显示“'cannot allocate memory'（errno=12）”（完整消息）。
对cloudwatch metrics和ganglia的调查显示 driver.jvm.heap.used 随着时间的推移正在稳步增长。
这两个观察结果都让我相信spark的某些长期运行组件（即高于工作级别）未能正确释放内存。重启hadoop yarn resourcemanager（如这里所示）会导致堆使用率下降到“fresh cluster”级别，这一点得到了支持。
如果我的假设是正确的-是什么导致Yarn不断消耗越来越多的内存(如果没有-我怎么能伪造呢？）
我从这里看到 spark.streaming.unpersist 默认为true（尽管我尝试添加了一个手册 rdd.unpersist() 不管怎样，在我的工作结束时，我只是想看看这是否有任何影响——它还没有运行到足够长的时间来明确地告诉我）
在这里，评论 spark.yarn.am.extraJavaOptions 表明，当运行在yarn客户机模式（我们现在是）， spark.yarn.am.memory 设置应用程序管理器堆内存的最大使用量。这个值在我们的作业中没有被覆盖（因此应该是512m的默认值），但是cloudwatch和ganglia都清楚地显示了以千兆字节为单位的驱动程序堆使用情况。