在Azure Databricks中减少因GC分配失败而导致的时间延迟步骤

Question

我在Azure Databricks Python笔记本上运行一个打印“Hello World”的作业，该作业运行在一个Spark集群中。每次运行作业时，它需要超过12秒才能执行，而实际上这个最简单的Python代码应该只需要不到12秒钟。当我查看日志时，发现以下GC分配失败信息：

2019-02-15T15:47:27.551+0000: [GC (Allocation Failure) [PSYoungGen: 312512K->57563K(390144K)] 498744K->243803K(1409024K), 0.0153696 secs] [Times: user=0.05 sys=0.00, real=0.02 secs] 
2019-02-15T15:47:28.703+0000: [GC (Metadata GC Threshold) [PSYoungGen: 206668K->65267K(385024K)] 392909K->251515K(1403904K), 0.0187692 secs] [Times: user=0.06 sys=0.00, real=0.02 secs] 
2019-02-15T15:47:28.722+0000: [Full GC (Metadata GC Threshold) [PSYoungGen: 65267K->0K(385024K)] [ParOldGen: 186248K->244119K(1018880K)] 251515K->244119K(1403904K), [Metaspace: 110436K->110307K(1144832K)], 0.3198827 secs] [Times: user=0.64 sys=0.04, real=0.32 secs] 

想知道是不是因为GC分配失败导致了工作延迟超过12秒？如果是，我应该如何减少它？如果不是，那么这种延迟的其他原因可能是什么，如何纠正呢？

- user39602

Answer 1

在集群上启动Spark作业存在额外开销。如果处理的是PB级别的数据，那么这种开销就很小，但在此情况下它是明显可见的。垃圾回收并不是问题所在。

- thebluephantom

---

谢谢您的回复。有没有办法减少这个开销？ - user39602

不，只是Spark的本质。 - thebluephantom

谢谢您的澄清。另外，您知道有没有任何方法可以重复使用Spark上下文？据我所知，每次在Spark上执行作业时，它都会创建一个Spark上下文，这最终会增加作业的启动时间。 - user39602

是的，这很有趣，因为spark-shell没有问题，但我怀疑您每次都在提交到集群，这会带来额外的开销。 - thebluephantom

GC不是问题，我希望你能看到这一点，并且这部分问题已经得到了回答。 - thebluephantom