一、癥狀表現(xiàn)

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

二、解決思路

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

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

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

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

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

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

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

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

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

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

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

打開(kāi)的socket文件數(shù)=1(DateNdoe)+7(child)+1(TaskTracker)=9個(gè)，打開(kāi)的socket文件數(shù)完全正常了，并且進(jìn)程號(hào)都對(duì)上了，集群也恢復(fù)正常！！！搞定收工！！！！！

三、總結(jié)

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

總結(jié)

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

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