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日志才能定位到问题。
    除了这个问题本身，最终得出以下结论：当谷歌已经无法解决问题的时候，考虑回归原理，结合环境辩证思考。另外一个就是在任何时候都不能忽略日志，哪怕只有很少的几个单词，在我们学习一个新的技术的时候，优先考虑怎么玩它的日志。好了就到这里了，希望这个能抛砖引玉，减少大家的时间浪费。