都说spark那么牛,有没有啥坑啊

您好,我是延云的技术,这个回答不好一概而论,毕竟我们也用了一年的spark。总体来说这东西还是非常不错的,当然也有一些地方不是很稳定的。
下面是我们这一年里,遇到的主要问题,比较偏技术,供您参考。
spark 内存泄露我们用的是 spark1.6.3,说实话,这个版本相比先前的版本已经稳定了很多,由于要给企业用,spark2.0刚出来不久,我们还在观望中。但是内存泄露的问题,真的是spark的硬伤。如果不能在企业中持续的使用不稳定,那么再快又有什么用呢?1.高并发情况下的内存泄露的具体表现
很遗憾,Spark的设计架构并不是为了高并发请求而设计的,我们尝试在网络条件不好的集群下,进行100并发的查询,在压测3天后发现了内存泄露。
a)在进行大量小SQL的压测过程中发现,有大量的activejob在spark ui上一直处于pending状态,且永远不结束,如下图所示
都说spark那么牛,有没有啥坑啊

b)并且发现driver内存爆满
都说spark那么牛,有没有啥坑啊

c)用内存分析分析工具分析了下
都说spark那么牛,有没有啥坑啊

2.高并发下AsynchronousListenerBus引起的WEB UI的内存泄露
短时间内 SPARK 提交大量的SQL ,而且SQL里面存在大量的 union与join的情形,会创建大量的event对象,使得这里的 event数量超过10000个event ,
一旦超过10000个event就开始丢弃 event,而这个event是用来回收 资源的,丢弃了 资源就无法回收了。 针对UI页面的这个问题,我们将这个队列长度的限制给取消了
都说spark那么牛,有没有啥坑啊

都说spark那么牛,有没有啥坑啊

3.AsynchronousListenerBus本身引起的内存泄露
抓包发现
都说spark那么牛,有没有啥坑啊

都说spark那么牛,有没有啥坑啊

这些event是通过post方法传递的,并写入到队列里
都说spark那么牛,有没有啥坑啊

但是也是由一个单线程进行postToAll的
都说spark那么牛,有没有啥坑啊

但是在高并发情况下,单线程的postToAll的速度没有post的速度快,会导致队列堆积的event越来越多,如果是持续性的高并发的SQL查询,这里就会导致内存泄露
接下来我们在分析下postToAll的方法里面,那个路径是最慢的,导致事件处理最慢的逻辑是那个?
都说spark那么牛,有没有啥坑啊

可能您都不敢相信,通过jstack抓取分析,程序大部分时间都阻塞在记录日志上
可以通过禁用这个地方的log来提升event的速度


推荐阅读