return code 2 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask

    运行环境:Hadoop2.8.0、Hive1.2.2,一共三台服务器,master是8G内存,两个slaver是4G内存(很寒酸),在Hive的命令行中执行count()和insert的时候总是报错,比如执行select count()的时候报“return code 2 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask”错误。很显然这个不是真正的问题,这是个很粗的异常,所以下一步需要查看真正JobTracker运行日志。由于是Hadoop2.8.0,而且也没有专门配置,日志的路径是:http://IP:8042,具体如何看日志这里不再赘述,大家可以查其他资料,查看日志后,所有的信息都是INFO级别的,只有一行是ERROR,这行的关键信息是:Could not deallocate container for task attemptId attempt_xxxxx(这里的xxxxx表示随机数),很明显是创建容器的时候出现问题了。网上资料很少,而且很多都是老外写的,总体归结为以下:
    1)nodemanager的内存不够;
    2)yarn.nodemanager.resource.memory-mb和yarn.scheduler.maximum-allocation-mb的值同倍数调整小了;经过辩证分析很显然这个都不是真正的原因。这个时候我们需要反过头查资料搞清楚这俩参数的含义。yarn.nodemanager.resource.memory-mb:指的是YARN可以分配的最大物理内存,要根据真实服务器的物理内存大小进行调整;yarn.scheduler.maximum-allocation-mb:指的是单个容器(JVM进程)可以申请的最大物理内存,很显然这个值是不能大于参数“yarn.nodemanager.resource.memory-mb”的值的。根据服务器的配置,将2个参数都调整为3072,结果还是不行,愁死人了。
    冷静了下,仔细想了下MR作业启动的时候也有内存参数,果不其然,查看了下文件mapred-site.xml后,里边有个参数mapreduce.reduce.memory.mb值是9000,这个参数的含义是:Reduce Task需要的内存。很显然这个是不对的,作业要运行在容器里,容器才3072,作业怎么能是9000呢?于是将该参数调整为1024,重启hadoop,重新在hive命令行执行select count(*)语句,华丽丽的返回了表的行数。
    当然了,中间经过的波折比这个多了很多,主要原因是刚接触这个技术,对Hadoop的体系和原理理解的太少。中间顺带解决了很多问题。比如在修改开头两个参数的时候,发现hadoop起不来了,原因是:yarn.nodemanager.resource.memory-mb这个参数的值比其中一台slave服务器的free内存大,如是种种。另外要注意,在有些情况下还会报:There are 2 datanode(s) running and 2 node(s) are excluded in this operation.可能也是这个原因引起的,当然了这个也不是直接异常,需要看具体的job日志才能定位到问题。
    除了这个问题本身,最终得出以下结论:当谷歌已经无法解决问题的时候,考虑回归原理,结合环境辩证思考。另外一个就是在任何时候都不能忽略日志,哪怕只有很少的几个单词,在我们学习一个新的技术的时候,优先考虑怎么玩它的日志。好了就到这里了,希望这个能抛砖引玉,减少大家的时间浪费。

你可能感兴趣的:(hive,hadoop)