江苏龙网

  1. 首页 > 生活 > >

spark现在都有那些BUG，性能怎样调优

您好，我是延云的技术，我们也用了一年的spark。总体来说这东西还是非常不错的，当然也有一些地方不是很稳定的。
下面是我们这一年里，遇到的主要问题，比较偏技术，供您参考。
spark 内存泄露我们用的是 spark1.6.3，说实话，这个版本相比先前的版本已经稳定了很多，由于要给企业用，spark2.0刚出来不久，我们还在观望中。但是内存泄露的问题，真的是spark的硬伤。如果不能在企业中持续的使用不稳定，那么再快又有什么用呢？1.高并发情况下的内存泄露的具体表现
很遗憾，Spark的设计架构并不是为了高并发请求而设计的，我们尝试在网络条件不好的集群下，进行100并发的查询，在压测3天后发现了内存泄露。
【spark现在都有那些BUG，性能怎样调优】 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的
但是在高并发情况下，单线程的postToAll的速度没有post的速度快，会导致队列堆积的event越来越多，如果是持续性的高并发的SQL查询，这里就会导致内存泄露
接下来我们在分析下postToAll的方法里面，那个路径是最慢的，导致事件处理最慢的逻辑是那个？
可能您都不敢相信，通过jstack抓取分析，程序大部分时间都阻塞在记录日志上
可以通过禁用这个地方的log来提升event的速度
log4j.logger.org.apache.spark.scheduler=ERROR
4.高并发下的Cleaner的内存泄露
说道这里，Cleaner的设计应该算是spark最糟糕的设计。spark的ContextCleaner是用于回收与清理已经完成了的 广播boradcast,shuffle数据的。但是高并发下，我们发现这个地方积累的数据会越来越多，最终导致driver内存跑满而挂掉。
l我们先看下，是如何触发内存回收的
没错，就是通过System.gc() 回收的内存，如果我们在jvm里配置了禁止执行System.gc，这个逻辑就等于废掉（而且有很多jvm的优化参数一般都推荐配置禁止system.gc 参数）
lclean过程
这是一个单线程的逻辑，而且每次清理都要协同很多机器一同清理，清理速度相对来说比较慢，但是SQL并发很大的时候，产生速度超过了清理速度，整个driver就会发生内存泄露。而且brocadcast如果占用内存太多，也会使用非常多的本地磁盘小文件，我们在测试中发现，高持续性并发的情况下本地磁盘用于存储blockmanager的目录占据了我们60%的存储空间。
我们再来分析下 clean里面，那个逻辑最慢
真正的瓶颈在于blockManagerMaster里面的removeBroadcast，因为这部分逻辑是需要跨越多台机器的。
针对这种问题，
l我们在SQL层加了一个SQLWAITING逻辑，判断了堆积长度，如果堆积长度超过了我们的设定值，我们这里将阻塞新的SQL的执行。堆积长度可以通过更改conf目录下的ya100_env_default.sh中的ydb.sql.waiting.queue.size的值来设置。
l建议集群的带宽要大一些，万兆网络肯定会比千兆网络的清理速度快很多。
l给集群休息的机会，不要一直持续性的高并发，让集群有间断的机会。
l增大spark的线程池，可以调节conf下的spark-defaults.conf的如下值来改善。


推荐阅读


上一篇：微信有 web API 吗

下一篇：程序员怎样说晚安