Hadoop運維記錄系列(二十二)
阿新 • • 發佈：2018-06-20
比較 p s lB 什麽 bar 而不是 細心 故障 duplex 今天抽空解決了一個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 interface 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 interface em1, 10 Mbps full duplex.
嗯，就是這個。
Hadoop運維記錄系列(二十二)