分享

Hadoop DataNode OOM故障及解决方案

问题导读:
1.出现oom的原因是什么?
2.解决OOM的思路是什么?





一、故障症状
跑大任务时,datanode日志报DataXceiveServer: Exiting due to:java.lang.OutOfMemoryError: unable to create new native thread异常,然后计算节点上的DataNode直接挂掉。DataNode异常日志截图如下:
2014-03-06 03:41:05,881 ERROR org.apache.Hadoop.hdfs.server.datanode.DataNode: DatanodeRegistration(172.16.8.5:50010, storageID=DS-2085721072-172.16.8.5-50010-1386684967398, infoPort=50075, ipcPort
=50020):DataXceiveServer: Exiting due to:java.lang.OutOfMemoryError: unable to create new native thread
TaskTracker上的异常日志信息:
2014-03-06 03:43:52,760 ERROR org.apache.hadoop.security.UserGroupInformation: PriviledgedActionException as:job_201403051809_0018 cause:java.io.IOException: Unknown task; attempt_201403051809_0018_r_000000_0. Ignoring getMapCompletionEvents Request
2014-03-06 03:43:52,760 ERROR org.apache.hadoop.security.UserGroupInformation: PriviledgedActionException as:job_201403051809_0018 cause:java.io.IOException: Unknown task; attempt_201403051809_0018_r_000000_0. Ignoring getMapCompletionEvents Request

二、解决故障思路分析
从TaskTracker的异常日志来看,报的是一个IO异常,反应的情况是无法从HDFS中获取到job的信息,另外日志中的“Ignoring getMapCompletionEvents Request”则是Reduce Task中的GetMapEventsThreads线程抛出的,该线程的主要作用是周期性通过RPC从TaskTracker获取已经完成的Map Task列表,为shuffle阶段做准备的。再联系DataNode上的异常日志信息我们知道DataNode进程由于出现OOM而挂掉了,那么在TaskTracker中获取不到HDFS上的作业信息也就可以解析了,因此得出一个结论:TaskTracker中的异常是由于DataNode进程挂掉引起的。接下来,将精力转到DataNode上的OOM分析。
TaskTracker报OOM异常我们见多了,最常见的就是reduce阶段的内存溢出,另外可能在map阶段中的sort和spill中,也就是io.sort.mb参数所控制的环形内存所做的快速排序上出现内存溢出,但是map阶段的内存溢出几率还是比较少的,因为通常默认情况下一个map只是处理一个数据块(一个block左右的大小),而且一般io.sort.mb设置都比一个block大小要大。另外TaskTracker上的OOM还可以通过mapred.map.child.java.opts来进行调整。那么对于现在这种情况,在DataNode上出现OOM,第一感觉是不是HADOOP_HEAPSIZE配置的太小了导致DataNode和TaskTracker进程不够内存用(这个值使用默认的1000m)?但是仔细想想觉得不怎么可能,因为集群是刚刚部署不久的,数据存储量还不是很多。但是为了测试还是将HADOOP_HEAPSIZE跳到了2000,再跑任务测试,不幸的是DataNode还是出现OOM,进而挂掉。此时,我想会不会是什么配置限制了内存的使用或者限制了新线程的创建?于是看看系统的限制参数,如下图:
temp_14030806303479.jpg
看了上面的参数,open files是当初改大了的,max user processes这个参数是系统默认的1024。起初对这个变量值的认识只是认为它仅仅限制了系统的最大进程数,又为了安全起见上网查查看,惊喜地发现,原来这个参数会对系统中所有application创建的总线程数有限制的(具体情况请参考:http://www.linuxidc.com/Linux/2014-03/97857p2.htm)。这样一下子明白什么回事了,将max user processes调大,调到81920(可以直接在bash_profiles添加ulimit -u 81920进行设置)。设置完了,如图:
temp_14030806317605.jpg
起任务再跑,观察DataNode日志,一切正常,不会出现OOM,稳!!
二、总结
OOM是hadoop集群运行时比较容易出现的故障,其解决方案也各有不同,要看实际情况而定。对于在Map或者reduce出现的OOM故障还是比较容易处理的,具体的可以看上面分析,对于DataNode中的OOM故障,其原因还是比较隐蔽的,需要一定的运维知识和工作经验的积累。



已有(1)人评论

跳转到指定楼层
pig2 发表于 2014-5-18 22:42:16
另外补充OOM是内存溢出的意思
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条