我们的Hadoop版本经历过0.20.X、1.0.3、2.3.0 ,在我手上经历过的主要是1.0.3 和2.3.0的版本，这期间遇到过一些问题，有些是经验不足导致，有些是不按规范操作引起的，有些是版本自身bug，正因为经历了这些问题才丰富了自身经 验，今天简单介绍一下这两年多我们遇到过的问题，希望对你能有一些借鉴。

---------------hadoop1.0.3-----------------

fsimage文件损坏 2012年9月,hadoop集群跨机房迁移，新机房供电不稳，突然掉电(只出现过这一次)导致namenode的fsimage文件损坏，启动namenode失败。想通过secondNamenode还原上个小时的fsimage，发现secondnamenode已经3天不work了,祸不单行。后面没办法只能分析调试源码，发现是hdfs目录树中有叶子目录找不到父节点，导致namenode启动报错，之后通过本地程序调试将游离的叶子删除，正常加载。故障从下午4点持续到晚上10点。惊心动魄！体会：越忙会越乱，越出状况要越冷静！

userlog 用户作业打印了大量system.out，导致磁盘频繁报警。解决方案：通过配置user.log.limit限制每个task的标准输出大小。

公平调度器 新集群统一采用了jdk1.7版本，jdk1.7默认的排序算法为timsort，如果用户同时提交两个资源使用差不多的作业，公平调度无法比较这两个作业的优先级，直接进入死循环判断，导致调度器不work。解决方案：将jobtraker的jdk 降回1.6。有兴趣的同学可以自行去研究下timsort算法。

jobTraker堆栈溢出 在hadoop 1.0中jobTraker 默认会在内存中保留历史作业，有两个条件：1.保留24小时,2.单用户保留最新的100个。第一次出现这种情况时比较紧张，啥都没看直接重启(后面变聪明遇到新情况都会注意先备份现场，再紧急恢复，以备后续分析)。之后基本是隔一个月出现一次故障。在没找到具体原因前，我们出了个策略，通知用户每月集群会例行维护一次，每次维护会提前一周通知。通过稍微降低服务质量来换取解决难题的时间。这个方法其实是非常有效的，特别是对一个技术储备、人力资源不足的团队。相同的手法我们在日志平台运营中也用到过。

上亿reduce用户通过shell提交作业，因参数输入错位导致设置了1亿个reduce，直接把JobTraker搞挂。解决方案：限制每个作业能提交的最大task数。

IPV6 因操作系统(centos5.8)支持ipv6，hadoop默认使用了ipv6建立连接，而交换机又不支持ipv6，导致出现大量的连接不能释放。解决方案：通过配置使其绑定到ipv4 。

HADOOP_OPTS=-Djava.net.preferIPv4Stack=true