一、癥狀表現(xiàn)

? ?前些時間公司在外省機房部署了一套新hadoop集群，所有機子都裝的是centos，跑了一個禮拜莫名其妙的出現(xiàn)了計算節(jié)點的心跳間隔變得越來越大，最終導(dǎo)致計算節(jié)點掛掉，遇到問題第一時間就是看日志...

二、解決思路

（1）看NameNode日志，一切正常。

（2）看心跳間隔大的節(jié)點上的taskTracker日志，轉(zhuǎn)到計算節(jié)點一切正常。

（3）看心跳間隔大的節(jié)點上的dataNode日志,轉(zhuǎn)到計算節(jié)點，并沒有任何異常。

我就納了悶啦，所有節(jié)點上日志看不出有任何異常。于是去看syslog日志信息，截了一段如下（節(jié)點一的信息slave01）：

都是一些系統(tǒng)內(nèi)核運行日志，也沒有任務(wù)異常信息。繼續(xù)查，用lsof看看計算節(jié)點打開的文件數(shù)目，這下子驚呆了，嚴重超標，竟然達到了385433。打開文件數(shù)遠遠超出系統(tǒng)設(shè)定的值81920：

具體看看具體打開的都是一些什么文件（部分截圖）:

相當奇怪，打開的幾乎都是socket文件，而且打開的socket文件數(shù)只增不減。按照正常沒有任何其它占socket連接的運行程序跑的情況下各個計算節(jié)點打開的socket文件數(shù)目應(yīng)該為：1(TaskTracker數(shù))+1(dataNode數(shù))+Child數(shù)(正在節(jié)點上運行的task數(shù))。以節(jié)點二為例，有一個Task在跑，如下圖，打開的socket文件數(shù)就應(yīng)該為：1+1+1=3個。

為什么會出現(xiàn)這種情況，是有人寫的mapreduce程序打開socket沒有關(guān)閉？為了排除這種情況，在集群中用hive進行一個簡單的sql查詢，再觀察打開的socket文件數(shù)，結(jié)果一查打開的socket文件數(shù)還是只增不減，現(xiàn)在可以排除人為性打開socket不關(guān)閉的情況了。回頭再瞄了一眼之前那個節(jié)點一打開socket文件的截圖，這時候發(fā)現(xiàn)這些socket文件的進程號都和節(jié)點一上的datanode進程號是一樣的，一個datanode打開了這么多socket文件？。一開始以為是bug，但是其他公司用我們hadoop1.2版本的就沒有這個問題，這點應(yīng)該可以排除掉。

? ?hadoop日志木有任何異常信息，系統(tǒng)日志木有任何信息！第一次見到種問題。上網(wǎng)查了下，發(fā)現(xiàn)有一個錯誤說法蠻像的，連接：http://my.oschina.net/JJREN/blog/78351，說是和centos的驅(qū)動版本有關(guān)系，于是毫不猶豫地將一臺計算節(jié)點的網(wǎng)卡驅(qū)動升級了，再測，還是一個鳥樣。這是要鬧哪樣啊!!!hadoop1.2在我們公司的另外一個裝ubuntu集群中運行得沒有任何問題，為何部署到centos上就會出現(xiàn)這種問題？難道是系統(tǒng)問題，這個一定不可能發(fā)生的，n家公司都是這個用，都沒有問題。再到計算節(jié)點看看JDK版本是否一致，結(jié)果都是一致的，但是....這里高潮來了。發(fā)現(xiàn)了一個奇怪的問題，所有節(jié)點的JDK都是ea版的！！如圖：

正常線上集群怎么裝的是ea版的，這個相當不合理啊！！于是去問之前裝系統(tǒng)的同事。他說這個JDK安裝文件和另外一個部署在ubuntu的hadoop集群時的安裝文件是一樣的。于是，立馬上上部署在ubuntu上的集群看JDK版本，一看主版本號都一樣，但不是ea版本并且構(gòu)建版本號不同。如圖：

我就奇怪啦，同一個JDK安裝文件在centos和ubuntu上安裝會產(chǎn)生不同的版本號？？（其實我懷疑是安裝的同事忘了，安裝文件應(yīng)該是不一樣的）于是將ubuntu上已經(jīng)安裝好的JDK復(fù)制到部署在centos上的集群，配置hadoop-env.sh文件，將hadoop的JDK環(huán)境指向新更新后非ea版的JDK。重啟集群，跑任務(wù)，測試，一切正常。看打開的socket文件數(shù)，如下:

打開的socket文件數(shù)=1(DateNdoe)+7(child)+1(TaskTracker)=9個，打開的socket文件數(shù)完全正常了，并且進程號都對上了，集群也恢復(fù)正常！！！搞定收工！！！！！

三、總結(jié)

? ?對于像這種非常規(guī)性集群出錯并且沒有任何日志異常信息的情況，真的不容易找到問題原因。但是解決問題的思路都是一樣的，先查hadoop日志看能不能查到原因，如果查不到原因就要看借助linux自帶的工具了，如lsof,strace,systat,netstat等。另外，syslog中的信息也是十分重要的，如果只看hadoop的log4j日志有可能永遠都找不到故障原因，因為log4j所記錄的是hadoop服務(wù)層的日志信息，它無法記錄更加底層的日志信息。最后，一個程序猿的直覺也是十分重要的，在你用盡了所有你能想到的方法，查遍了網(wǎng)絡(luò)上所有有關(guān)的信息都無法找到故障原因時，這種直覺往往會其到重要的作用，它會引導(dǎo)你往另外一個可能找到問題原因的方向去思考。但是我覺得這種直接不是憑空而來的，而是從日常的工作經(jīng)驗中積累的。

總結(jié)

以上是生活随笔為你收集整理的记一则神秘JDK版本引发的hadoop集群慢性崩溃”血案“的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。