Spark SQL踩坑经验总结及调优分享

写在之前：

本篇文章写就时间较早，因此本文所讨论的Spark SQL非最新版本，后续更新版本可能有部分修复和更新。

一、Spark内存泄露

1.高并发情况下的内存泄露的具体表现

首先得很遗憾的告诉各位，Spark在设计之初的架构就不是为了高并发请求而生的，我们尝试在网络条件不好的集群下，进行100并发的查询，在压测3天后发现了内存泄露。

在进行大量小SQL的压测过程中发现，有大量的activejob在spark ui上一直处于pending状态，且永远不结束，如下图所示：

并且发现driver内存爆满：

我们通过内存分析工具分析了下：

2.高并发下AsynchronousListenerBus引起的WEB UI的内存泄露

短时间内 Spark 提交大量的SQL ，而且SQL里面存在大量的 union与join的情形，会创建大量的event对象，使得这里的event数量超过10000个event 。

一旦超过10000个event就开始丢弃 event，而这个event是用来回收资源的，丢弃了资源就无法回收了。 针对UI页面的这个问题，我们将这个队列长度的限制给取消了。

3.AsynchronousListenerBus本身引起的内存泄露

通过抓包我们发现：

这些event是通过post方法传递的，并写入到队列里。

但是也是由一个单线程进行postToAll的：

但是在高并发情况下，单线