1. 程式人生 > >Hadoop運維記錄系列(二十二)

Hadoop運維記錄系列(二十二)

比較 p s lB 什麽 bar 而不是 細心 故障 duplex

今天抽空解決了一個Hadoop集群的一個非常有意思的故障,之所有有意思,是這個故障既可以稱之為故障,又不算是故障,說不算問題吧,作業跑的特慢,說算問題吧,作業不但都能跑出來,還沒有任何報錯,所以還比較難查。

故障表象是一幫人嚷嚷作業太慢了,跑不動,但是基本上嚷嚷一會就能跑出來,但相對於原來還是慢。我看了下,確實比較慢,有些作業一個map要半小時,但不是所有作業都這樣,部分作業就很快,沒有什麽規律可循。

好吧,我們來著手分析一下慢查詢作業。因為解決以後都嗖嗖的跑完了,所以沒有截圖。以下完全靠文字描述。

在Yarn裏打開某個被投訴慢的作業,進入AM的頁面,一路進去到map頁面,看到某個map,10多分鐘了,才跑了0.2%,這必須不能忍。

  1. 復制該map的作業號。

  2. 進入該map所在的節點,查看該map attempt的進程號。

  3. 查看該進程的系統調用,看到該map進程建立了兩個TCP連接,其中一個是某個DN的50010端口,好的,50010端口是數據塊傳輸端口。

  4. 再檢查幾個慢的map進程,發現一個規律,這些慢的map進程都連接了同一個DN的50010。那麽基本可以推定問題出在這個DN上。

  5. 登上這個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運維記錄系列(二十二)