最近的工作有很大一部分是在做用户画像。
画像读取的维度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的数量。
大体上就是这样。
发表评论