今天抽空解決了乙個hadoop集群的乙個非常有意思的故障，之所有有意思，是這個故障既可以稱之為故障，又不算是故障，說不算問題吧，作業跑的特慢，說算問題吧，作業不但都能跑出來，還沒有任何報錯，所以還比較難查。
故障表象是一幫人嚷嚷作業太慢了，跑不動，但是基本上嚷嚷一會就能跑出來，但相對於原來還是慢。我看了下，確實比較慢，有些作業乙個map要半小時，但不是所有作業都這樣，部分作業就很快，沒有什麼規律可循。
好吧，我們來著手分析一下慢查詢作業。因為解決以後都嗖嗖的跑完了，所以沒有截圖。以下完全靠文字描述。
在yarn裡開啟某個被投訴慢的作業，進入am的頁面，一路進去到map頁面，看到某個map，10多分鐘了，才跑了0.2%，這必須不能忍。
複製該map的作業號。
進入該map所在的節點，檢視該map attempt的程序號。
檢視該程序的系統呼叫，看到該map程序建立了兩個tcp連線，其中乙個是某個dn的50010埠，好的，50010埠是資料塊傳輸埠。
再檢查幾個慢的map程序，發現乙個規律，這些慢的map程序都連線了同乙個dn的50010。那麼基本可以推定問題出在這個dn上。
登上這個dn，shutdown掉datanode和nodemanager。故障解除，任務又都飛起來了。
到這裡故障是排除了，但是原因還不清楚，繼續發掘原因。
由於只是慢，而不是完全跑不出來，大不了慢的map reduce attempt最後被kill掉了拿到其他伺服器重新跑，但是不會報任何錯誤日誌，系統log也沒有錯誤日誌。連warn基本的都沒有。但細心如我，還是發現了問題。
syslog裡面的記錄
jun 19 14:05:45 6 kernel: bonding: bond0: link status definitely down for inte***ce em1, disabling it
jun 19 14:06:22 6 kernel: tg3 0000:01:00.0: em1: link is up at 10 mbps, full duplex
jun 19 14:06:22 6 kernel: tg3 0000:01:00.0: em1: flow control is off for tx and off for rx
jun 19 14:06:22 6 kernel: tg3 0000:01:00.0: em1: eee is disabled
jun 19 14:06:22 6 kernel: bond0: link status definitely up for inte***ce em1, 10 mbps full duplex.
Hadoop運維記錄系列 二十三
最近做集群機房遷移，在舊機房和新機房之間接了根專線，做集群不停機搬遷，也就是跨機房，同時要新加百多台伺服器，遇到幾個問題，記錄一下。舊集群的機器是centos 6,新機房加的機器是centos 7。一 丟包問題 在跨機房的時候，datanode顯示很多slow blockreceiver的日誌 wa...
Hadoop運維記錄系列 十七
上個月通過email，幫朋友的朋友解決了乙個cloudera的spark sql無法訪問hbase做資料分析的問題，記錄一下。首先，對方已經做好了hive訪問hbase，所以spark sql原則上可以通過呼叫hive的元資料來訪問hbase。但是執行極慢，而且日誌無報錯。中間都是郵件溝通，先問了幾...
Hadoop運維記錄系列 九
linux作業系統針對hadoop的引數和命令調優。對於hadoop本身的引數調優，寫的已經不少了，作業系統方面的不多，記錄一下我用的系統引數。先寫一點，想起哪個再往裡面加。一 系統核心引數調優sysctl.conf net.ipv4.ip forward 0 net.ipv4.conf.defau...