基于spark之上的即席分析-spark内存泄漏及源码调优

spark 内存泄露

1. 高并发情况下的内存泄露的具体表现 
   很遗憾， spark 的设计架构并不是为了高并发请求而设计的，我们尝试在网络条件不好的集群下，进行 100 并发的查询，在压测 3 天后发现了内存泄露。 
   a) 在进行大量小 SQL 的压测过程中发现，有大量的 activejob 在 spark ui 上一直处于 pending 状态，且永远不结束，如下图所示 
    
   b) 并且发现 driver 内存爆满 
    
   c) 用内存分析分析工具分析了下 
   

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

3. AsynchronousListenerBus 本身引起的内存泄露 
   抓包发现 
    
    
   这些 event 是通过 post 方法传递的，并写入到队列里 
    
   但是也是由一个单线程进行 postToAll 的