最近的工作有很大一部分是在做用户画像。
画像读取的维度bitmap动辄几百MB,甚至存在部分GB级别的。而我们的Yarn集群规模比较小,内存总计只有100多GB。开发调试时遇到最多的问题除了Task not serializable就是heap out of memeory了。
我们使用的Spark版本是1.6.3。yarn集群使用的jdk版本是1.7。
如何解决堆内存溢出是最大的难题 。
这时的分析受惠于这几个jvm虚拟机参数“-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps ”很多。根据这些参数可以看到内存使用的详情。比如我这里曾遇到过新生代内存使用率达到了99%,而老年代使用率只有20%多的情况,此时需要适当调整新生代和老年代的比例。另外还尝试过使用“-XX:+HeapDumpOnOutOfMemoryError ”获取溢出时的内存快照,如果找到快照的话就可以找出是哪些对象占用了最多的内存,也有很大的几率定位到发生溢出的位置。可惜运维没有找到快照。
另一种情况出现在代码上。比如从ByteWritable获取字节数组时有两个API可用,一个是copyBytes(),一个是getBytes(),使用copyBytes可以把指定区间内的字节数组copy出来,但是这样一来占用的内存肯定是要double了。又比如该使用broadcast变量的时候使用了普通变量,该使用mapPartitions的时候使用了map。写代码的时候每调用一个方法都应该考虑一下相关的开销。
我这里遇到的内存溢出一般来说就是最简单的情况——内存是真的不够用了。某些需要加载到内存里的bitmap体量实在太大,因为整体的资源不足,同时又有其他的任务在跑,所以不能过分上调executor内存。这样能做的只有限制executor的数量,才能适当增加executor的内存。并且为了避免一个executor内可能会出现多个过大bitmap同时并行运算的问题还得限制某些stage的partition数量。更极端的情况就得限制每个executor的core的数量。
大体上就是这样。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。