一、故障症状

最近公司一个集群跑大任务时，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，进而挂掉。此时，我想会不会是什么配置限制了内存的使用或者限制了新线程的创建？于是看看系统的限制参数，如下图：

看了上面的参数，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故障，其原因还是比较隐蔽的，需要一定的运维知识和工作经验的积累。哎，都深夜了，就记录这么多了，睡觉！！