网站开发类书籍,杭江建设有限公司,成都网站建设好,驻马店广告制作公司一、故障症状最近公司一个集群跑大任务时#xff0c;datanode日志报DataXceiveServer: Exiting due to:java.lang.OutOfMemoryError: unable to create new native thread异常#xff0c;然后计算节点上的DataNode直接挂掉。DataNode异常日志截图如下#xff1a;2014-03-06 …一、故障症状 最近公司一个集群跑大任务时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, storageIDDS-2085721072-172.16.8.5-50010-1386684967398, infoPort50075, ipcPort50020):DataXceiveServer: Exiting due to:java.lang.OutOfMemoryError: unable to create new native threadTaskTracker上的异常日志信息: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 Request2014-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进而挂掉。此时我想会不会是什么配置限制了内存的使用或者限制了新线程的创建于是看看系统的限制参数如下图看了上面的参数open files是当初改大了的max user processes这个参数是系统默认的1024。起初对这个变量值的认识只是认为它仅仅限制了系统的最大进程数又为了安全起见上网查查看惊喜地发现原来这个参数会对系统中所有application创建的总线程数有限制的具体情况请参考http://www.iteye.com/topic/654172。这样一下子明白什么回事了将max user processes调大调到81920可以直接在bash_profiles添加ulimit -u 81920进行设置。设置完了如图起任务再跑观察DataNode日志一切正常不会出现OOM稳二、总结 OOM是hadoop集群运行时比较容易出现的故障其解决方案也各有不同要看实际情况而定。对于在Map或者reduce出现的OOM故障还是比较容易处理的具体的可以看上面分析对于DataNode中的OOM故障其原因还是比较隐蔽的需要一定的运维知识和工作经验的积累。哎都深夜了就记录这么多了睡觉
