线上一个Hive(CDH4.2.0)的清洗Job出错,查看日志发现其中一个MAP OOME:
查看了日志这个HQL是2个表进行Join,splits=2即开了2个MAP进行分别处理,其中一个大表123MB(),500W行左右,应该是数据量超过了MAP的内存了,通过对比前一天的日志可以确认:
由于是临时表,设置了mapred.reduce.tasks=20重跑新生成临时表,Join清洗成功:
由于MR的inputsplit size=min{minsplitsize,max{maxsplitsize,blocksize}},因此想是否可以通过设置mapred.max.split.size=32MB来起多个MAP这种方式解决呢,尝试后发现仍然是2个MAP;Google后无果(都是减小MAP数的方法,so easy)祭出杀器:看源码;
computeSplitSize(long goalSize, long minSize, long blockSize) {
return Math.max(minSize, Math.min(goalSize, blockSize)); }
丫的这个参数根本就没用上,再看CDH3u1的代码:
computeSplitSize(long blockSize, long minSize, long maxSize) {
return Math.max(minSize, Math.min(maxSize, blockSize)); }
这个参数在 CDH3 是有效的,看来是 CDH 回归的一个 Bug ;后来通过设置 mapred.map.tasks 增加果然起了预期的 MAP 数,唉,升级需谨慎啊![@more@]来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/11676357/viewspace-1060923/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/11676357/viewspace-1060923/