今天记录一下使用Hql遇到的一个问题map=100%和reduce=100%都执行完了本以为能出结果了，最后突然报了一个Bug，果然生活处处充满着意外与惊喜，这…只能说是有惊无喜
我看到这个Bug之后，查看hive的日志发现，跟执行hive的界面报的是一样，看不出啥东西出来，后来使用hadoop的history：8088查看聚合的日志，发现在UI这里是启动了4个map一个reduce，reduce是没有logs的看来是map没有没有完成，导致reduce无法工作，点进其中的一个map查看日志发现报的错，才是问题的根源，堆溢出了，以及虚拟内存不足的原因导致map被干掉了
重点的几个数字简单做一下详解
110.2 MB of 1 GB
3.7 GB of 2.1 GB virtual memory used. Killing container
1、110.2MB 是这个任务的实际物理内存
2、1GB 是mapreduce.map.memory.mb 设置的 （默认的）
3、3.7GB是任务要占用的虚拟内存
4、2.1GB是mapreduce.map.memory.db 乘以 yarn.nodemanager.vmem-pmem-ratio 得到的
5、其中yarn.nodemanager.vmem-pmem-ratio 是 虚拟内存和物理内存比例，在yarn-site.xml中设置，默认是2.1
假如我本地设置的是3， 其值计算就是1*3 = 3GB
综上所述 日志告诉我们的就是任务所要的虚拟内存是3.7G 而系统只有2.1G的虚拟内存，超出上限无法工作了，这里超出的只是虚拟内存跟实际内存还是有区别的不懂的自行百度这方面的知识
所以解决的方法有以下几个方面
在yarn-site.xml中设置关闭虚拟内存的检查 （默认是True开启的状态）
<property>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
<description>Whether virtual memory limits will be enforced for containers.</description>
</property>
本人根据自已配置，以及处理的数据量发现内存是够的，总的来说是因为这个虚拟的内存检查机制限制住了所以就只配置了这个，任务就能继续执行下去了
在yarn-site.xml 中物理内存的检查也是可以关闭的
<property>
<name>yarn.nodemanager.pmem-check-enabled </name>
<value>false</value>
<description>Whether virtual memory limits will be enforced for containers.</description>
</property>
不过一般不建议这么设置 因为 如果程序有内存泄漏等问题，取消这个检查，可能会导致集群崩溃。
还有就是可能物理内存不足导致程序无法启动，增大物理内存
在mapred-site.xml中 根据处理的数据量适当调整以下参数的值 ：2048 、-Xmx1024M自行设置合适的值
<property>
<name>mapreduce.map.memory.mb</name>
<value>2048</value>
</property>
<property>
<name>mapreduce.map.java.opts</name>
<value>-Xmx1024M</value>
</property>
<property>
<name>mapreduce.reduce.memory.mb</name>
<value>2048</value>
</property>
<property>
<name>mapreduce.reduce.java.opts</name>
<value>-Xmx2560M</value>
</property>
可以适当调整yarn.nodemanager.vmem-pmem-ratio的大小，因为虚拟内存是受物理内存这个比例影响的
还有可能是MR在跑的过程中数据倾斜了、内存泄露等等原因这个只能具体原因具体分析了
更改了yarn-site.xml配置文件后记得要把yarn集群重启
