江苏龙网

  1. 首页 > 生活 > >

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


5.线程池与threadlocal引起的内存泄露
发现spark，Hive，lucene都非常钟爱使用threadlocal来管理临时的session对象，期待SQL执行完毕后这些对象能够自动释放，但是与此同时spark又使用了线程池，线程池里的线程一直不结束，这些资源一直就不释放，时间久了内存就堆积起来了。
针对这个问题，延云修改了spark关键线程池的实现，更改为每1个小时，强制更换线程池为新的线程池，旧的线程数能够自动释放。
6.文件泄露
您会发现，随着请求的session变多，spark会在hdfs和本地磁盘创建海量的磁盘目录，最终会因为本地磁盘与hdfs上的目录过多，而导致文件系统和整个文件系统瘫痪。在YDB里面我们针对这种情况也做了处理。
7.deleteONExit内存泄露
为什么会有这些对象在里面，我们看下源码
8.JDO内存泄露
多达10万多个JDOPersistenceManage
9.listerner内存泄露
通过debug工具监控发现，spark的listerner随着时间的积累，通知(post)速度运来越慢
发现所有代码都卡在了onpostevent上
jstack的结果如下
研究下了调用逻辑如下，发现是循环调用listerners，而且listerner都是空执行才会产生上面的jstack截图
通过内存发现有30多万个linterner在里面
发现都是大多数都是同一个listener,我们核对下该处源码
最终定位问题
确系是这个地方的BUG ，每次创建JDBC连接的时候 ，spark就会增加一个listener， 时间久了，listener就会积累越来越多 针对这个问题 我简单的修改了一行代码，开始进入下一轮的压测
二十二、spark源码调优测试发现，即使只有1条记录，使用 spark进行一次SQL查询也会耗时1秒，对很多即席查询来说1秒的等待，对用户体验非常不友好。针对这个问题，我们在spark与hive的细节代码上进行了局部调优，调优后，响应时间由原先的1秒缩减到现在的200~300毫秒。
以下是我们改动过的地方
1.SessionState 的创建目录 占用较多的时间
另外使用Hadoop namenode HA的同学会注意到，如果第一个namenode是standby状态，这个地方会更慢，就不止一秒，所以除了改动源码外，如果使用namenode ha的同学一定要注意，将active状态的node一定要放在前面。
2.HiveConf的初始化过程占用太多时间
频繁的hiveConf初始化，需要读取core-default.xml,hdfs-default.xml,yarn-default.xml
,mapreduce-default.xml,hive-default.xml等多个xml文件，而这些xml文件都是内嵌在jar包内的。
第一，解压这些jar包需要耗费较多的时间，第二每次都对这些xml文件解析也耗费时间。
3.广播broadcast传递的hadoop configuration序列化很耗时
lconfiguration的序列化，采用了压缩的方式进行序列化，有全局锁的问题
lconfiguration每次序列化，传递了太多了没用的配置项了，1000多个配置项，占用60多Kb。我们剔除了不是必须传输的配置项后，缩减到44个配置项，2kb的大小。
4.对spark广播数据broadcast的Cleaner的改进
由于SPARK-3015 的BUG，spark的cleaner 目前为单线程回收模式。
大家留意spark源码注释
其中的单线程瓶颈点在于广播数据的cleaner，由于要跨越很多台机器，需要通过akka进行网络交互。
如果回收并发特别大，SPARK-3015 的bug报告会出现网络拥堵，导致大量的 timeout出现。
为什么回收量特变大呢？ 其实是因为cleaner 本质是通过system.gc（）,定期执行的，默认积累30分钟或者进行了gc后才触发cleaner,这样就会导致瞬间，大量的akka并发执行，集中释放，网络不瞬间瘫痪才不怪呢。
但是单线程回收意味着回收速度恒定，如果查询并发很大，回收速度跟不上cleaner的速度，会导致cleaner积累很多，会导致进程OOM（YDB做了修改，会限制前台查询的并发）。


推荐阅读


上一篇：微信有 web API 吗

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