Stage过多导致的内存溢出
2017-10-23 本文已影响0人
Artisan_848c
问题描述：
负荷清洗项目时，按天加载运行。运行40多天没有问题，当运行天数更多的时候，开始出现
Exception in thread "dispatcher-event-loop-31"
java.lang.OutOfMemoryError: GC overhead limit exceeded
同时，jconsole中堆内存监控呈现逐渐上升的趋势
经过一段时间后，堆内存占用率、PS Eden Space、PS Old gen接近100%。
排查过程：
1.内存溢出跟Old gen资源无法释放有关。
2.使用top命令查找当前程序运行的PID
[root@dw212 ~]# top
找到CPU占比最高且用户是root（启动脚本使用的用户名）的进程PID
3.使用jmap将内存对象信息dump下来
[root@dw212 cdTest]# jmap -dump:format=b,file=文件名.hprof PID
例如此处为：
[root@dw212 cdTest]# jmap -dump:format=b,file=jmap1.hprof 20139
Dumping heap to /home/cdTest/jmap.hprof ...
Heap dump file created
命令结束后会在执行该命令的目录下生成jmap1.hprof文件，将文件保存到本地
4.使用JProfiler工具打开该文件
可以看到不同的class所占用内存的实例个数和字节数
此处看到排除基本数据类型后HashMap、colon等class数量异常多。
点击Biggest Objects
发现org.apache.spark.ui.jobs.JobProgressListener异常大
点开后发现是一个名为stageIdToData的变量占据了大量内存
5.代码跟踪
打开org.apache.spark.ui.jobs.JobProgressListener的源代码
微信截图_20171023192818.png
不仅发现大量HashMap变量，并且看到了stageIdToData变量名
查找该变量数据清除的方法
继续跟踪retainedStages变量的初始值
发现该初始值为1000
回到Spark Master的Web管理界面找到OOM的任务，发现系统发生OOM的时候Job数量在200+，stage数量在400+，都未达到系统设定的1000，因此该部分数据一直存在内存中，占用了大量old gen空间。
6.修复
在启动脚本中加入两个参数，手动设置job和stage的释放阈值
--conf spark.ui.retainedJobs=16
--conf spark.ui.retainedStages=64
其中的16和64是计算得到的，计算过程如下
- 将需要循环的任务循环次数设定为1，运行程序。
- 在Spark Master的Web界面中统计程序运行1次时所产生的Job和Stage的数量。
- 将所得的数量乘以5（经验值，可随意）配置成为参数。
7.修复结果
堆
Old Gen
8.总结
Spark程序在运行时会在Web端缓存历史的Stage和Job的状态，其中有大量的数据，如果集群的JVM内存空间有限，就需要格外注意这类的OOM。解决思路有三个。
- 优化代码，合并冗余的Job和Stage。
- 提高JVM的内存大小。
- 修改spark.ui.retainedJobs及spark.ui.retainedStages的大小。修改这两个参数时一定要注意，不要过小，当小到一次循环（一次大计算量）都无法完成时，会出现任务起初加载的资源在还未用完时就被释放了。
