我們的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