G1GC对于大火花应用是稳定的吗？

Question

我们的数据管道目前正在Spark2.4和javaVersion1.8上运行，执行所有ETL步骤大约需要10个小时。

目前，我们注意到驱动程序内存堆被提升，并在管道的末尾造成大量的GCs (堆被赋予70G )，即使所有的GCs都处于最高级别，请记住这是火花驱动程序。

在用-XX:+UseParallelGC进行测试之后，我们目前正在使用-XX:+UseG1GC。我们注意到，完整GC的数量下降了很多，因此考虑改为G1GC。但是我从同事那里听说，几年前G1GC并不稳定，我想知道G1GC现在对于大型星火应用程序是否稳定GC (在我们的例子中，运行10+小时，50G+堆大小)

Answer 1

(这是一个不断增长的评论)

首先，听起来好像你有一个记忆leak.Just从你的描述，它听起来像是你没有解放老一代。转移到G1并不能解决这个问题。

请注意，我不熟悉您的特定用例，也不知道是否存在延迟需求。

尽管如此，我们有运行J8的g1和800 GB (有时更大，记录为1.5TB)堆的实例，没有任何重大问题。

请注意，在这种堆大小下，可能会出现奇怪的边缘情况，并且配置可能是脆弱的。但它被用于生产。

有一点值得注意的是，HW线程的数量非常重要。即使大多数时候他们什么也不做，一旦gc进入混合循环，hw线程的数量就变得非常重要。

一般来说，如果这是一个批处理式的应用程序，没有延迟需求，那么请与并行收集器保持在一起，并修复内存泄漏。G1并发地消耗cpu，而并行收集器不消耗cpu。