在Hadoop集群從1.0升級(jí)到2.0之后，我們一直在解決很多很多的問(wèn)題。在今年8月初，我們檢測(cè)到線上頻繁有機(jī)器變成死亡結(jié)點(diǎn)，一段時(shí)間后自動(dòng)恢復(fù)。進(jìn)入死亡結(jié)點(diǎn)狀態(tài)的DataNode將不能讀寫數(shù)據(jù)塊。我們觀察了一下日志，看到DataNode中打印出很多接受數(shù)據(jù)快傳輸?shù)木€

在Hadoop集群從1.0升級(jí)到2.0之后，我們一直在解決很多很多的問(wèn)題。在今年8月初，我們檢測(cè)到線上頻繁有機(jī)器變成死亡結(jié)點(diǎn)，一段時(shí)間后自動(dòng)恢復(fù)。進(jìn)入死亡結(jié)點(diǎn)狀態(tài)的DataNode將不能讀寫數(shù)據(jù)塊。我們觀察了一下日志，看到DataNode中打印出很多接受數(shù)據(jù)快傳輸?shù)木€程(DataXceiver)，線程都是在Receiving的狀態(tài)，而沒(méi)有結(jié)束。估摸了一下在死亡結(jié)點(diǎn)發(fā)生的階段大約有300個(gè)左右的線程積累下來(lái)。但是，沒(méi)找到其它突破口。

由于，HDFS的Client會(huì)自動(dòng)重試。如果一個(gè)結(jié)點(diǎn)進(jìn)入死亡結(jié)點(diǎn)，只要另外的數(shù)據(jù)塊的結(jié)點(diǎn)依然可讀，Client還是可以讀取到數(shù)據(jù)塊的。所以，死亡結(jié)點(diǎn)的問(wèn)題對(duì)線上業(yè)務(wù)沒(méi)有造成影響。當(dāng)時(shí)，還有其它優(yōu)先級(jí)更高的事情，所以，問(wèn)題轉(zhuǎn)為觀察狀態(tài)。

然后終于在一次機(jī)房意外斷電，集群重啟之后，一個(gè)線上的作業(yè)報(bào)找不到數(shù)據(jù)塊。經(jīng)日志確認(rèn)，產(chǎn)生的原因是擁有這個(gè)數(shù)據(jù)塊副本的兩個(gè)機(jī)器同時(shí)進(jìn)入死亡結(jié)點(diǎn)！ 于是，問(wèn)題轉(zhuǎn)入高優(yōu)先級(jí)，優(yōu)先解決。

現(xiàn)象總結(jié)

攻堅(jiān)

首先知道，DataNode進(jìn)入死亡結(jié)點(diǎn)狀態(tài)是因?yàn)镹ameNode長(zhǎng)期接收不到DataNode的心跳包，就會(huì)把DataNode歸入死亡結(jié)點(diǎn)。而DataNode的心跳線程是單獨(dú)一個(gè)線程。

現(xiàn)象的最后一點(diǎn)，6小時(shí)的間隔，可謂是這個(gè)問(wèn)題的突破點(diǎn)。在配置文件中找到6小時(shí)的間隔的工作有兩種：

1. DataNode和NameNode的6小時(shí)一次的心跳報(bào)告。用于更新NameNode上的Block信息。
2. DataNode每6小時(shí)一次的磁盤掃描。用于更新內(nèi)存中的信息和磁盤中信息的不一致。

根據(jù)兩者打印的日志和死亡結(jié)點(diǎn)發(fā)生的時(shí)間進(jìn)行精確對(duì)比，發(fā)現(xiàn)后者的時(shí)間基本吻合。 然后，我們?cè)诩胁榭创疟P掃描(DirectoryScanner)的代碼。

描述一下磁盤掃描的工作流程：

1. 啟動(dòng)一個(gè)主線程和一個(gè)線程池。
2. 主線程往線程池提交多個(gè)磁盤掃描的任務(wù)。任務(wù)是遍歷整個(gè)數(shù)據(jù)目錄記錄所有的數(shù)據(jù)塊的信息和對(duì)應(yīng)的Meta信息
3. 主線程等待線程池的任務(wù)返回，收集掃描結(jié)果。
4. 將掃描結(jié)果和內(nèi)存中的數(shù)據(jù)塊進(jìn)行對(duì)比，得到DiffRecord，算法復(fù)雜度O(n)，數(shù)據(jù)塊越多速度越慢。
5. 根據(jù)DiffRecord修改對(duì)應(yīng)的內(nèi)存數(shù)據(jù)。

第一步，主線程和線程池的線程都是Daemon線程。Daemon線程的默認(rèn)優(yōu)先級(jí)比較低。

第二步，由于涉及到磁盤讀寫。如果，外部磁盤壓力大的時(shí)候，會(huì)拖慢整個(gè)進(jìn)度。但是，整個(gè)過(guò)程沒(méi)有加鎖。不可能對(duì)其它線程產(chǎn)生影響。

第四步，數(shù)據(jù)塊對(duì)比過(guò)程，為了阻止對(duì)blockMap的修改，整個(gè)過(guò)程針對(duì)DataSet對(duì)象加鎖(DataSet對(duì)象是DataNode中保存所有數(shù)據(jù)塊信息的內(nèi)存對(duì)象)。

那心跳進(jìn)程為什么會(huì)使用DataSet的對(duì)象鎖? 我們寫了個(gè)小程序測(cè)試，在對(duì)DataSet加鎖的情況下，啟動(dòng)心跳線程。發(fā)現(xiàn)心跳線程在獲取磁盤的可用空間的時(shí)候，需要獲得DataSet的鎖。

于是，問(wèn)題變得清晰了：在6小時(shí)一次的磁盤掃描中，由于DirectoryScanner長(zhǎng)久占用了DataSet的鎖，導(dǎo)致心跳線程不能發(fā)出心跳包。DataNode進(jìn)入死亡結(jié)點(diǎn)狀態(tài)。而問(wèn)題頻發(fā)在磁盤較多的機(jī)器是因?yàn)椋瑪?shù)據(jù)塊數(shù)量和對(duì)比的過(guò)程的耗時(shí)相關(guān)。那是什么原因?qū)е翫irectoryScanner長(zhǎng)久占用了DataSet的鎖呢?

我們觀察了加鎖部分的代碼，沒(méi)有找到磁盤操作。我們估摸了下，最多數(shù)據(jù)塊的機(jī)器也才80W左右各數(shù)據(jù)塊。如果是純內(nèi)存操作，不可能占用鎖長(zhǎng)達(dá)10分鐘甚至30分鐘之久。

然后我們將懷疑的地方鎖定在主線程的Daemon屬性。因?yàn)椋珼aemon屬性的線程優(yōu)先級(jí)較低，懷疑是主線程在多線程的情況下，分配不到CPU時(shí)間片。

于是，我們作出第一個(gè)修改：將主線程改為普通線程的優(yōu)先級(jí)。

上線第二天，死亡結(jié)點(diǎn)現(xiàn)象還是出現(xiàn)，現(xiàn)象出現(xiàn)的時(shí)間相對(duì)來(lái)說(shuō)是短了點(diǎn)，但還是不能解決問(wèn)題。

于是，我們開(kāi)了個(gè)大招：針對(duì)死亡結(jié)點(diǎn)頻發(fā)的結(jié)點(diǎn)，加上一個(gè)每分鐘打印一次DataNode的jstack的腳本。

終于我們捕獲了在死亡結(jié)點(diǎn)發(fā)生時(shí)候的幾個(gè)堆棧。經(jīng)過(guò)對(duì)比分析，得出的結(jié)論是：

(呵呵)數(shù)據(jù)塊對(duì)比過(guò)程中，有一個(gè)使用Java的File對(duì)象的獲取文件長(zhǎng)度的getlength方法。而這個(gè)方法是直接調(diào)用一個(gè)native方法，獲取磁盤上文件的長(zhǎng)度。

當(dāng)初我們就猜想，加鎖部分是否有磁盤的IO操作。因?yàn)镮O操作的快慢，會(huì)受到當(dāng)時(shí)的機(jī)器狀態(tài)影響很大。不得不說(shuō)，這個(gè)位置太隱蔽了。看了很久都沒(méi)發(fā)現(xiàn)，還好有jstack截獲出來(lái)。

總結(jié)

6小時(shí)一次的DirectoryScanner在數(shù)據(jù)塊對(duì)比過(guò)程中，會(huì)對(duì)DataSet加鎖。如果，機(jī)器的磁盤壓力很高的情況下，對(duì)比過(guò)程中的磁盤操作十分耗時(shí)。導(dǎo)致DirectoryScanner長(zhǎng)期持有DataSet的鎖，阻塞心跳線程和所有的DataXceiver的線程。DataNode變成死亡結(jié)點(diǎn)。一段時(shí)間后，對(duì)比過(guò)程結(jié)束。DataSet鎖釋放，DataNode回歸正常工作。

解決

知道問(wèn)題了就好解決了。我們采取的方式是把getlength操作提取到第二步的線程池的異步磁盤掃描中進(jìn)行。

部署到線上后，數(shù)據(jù)對(duì)比時(shí)間降低到2秒左右。至此，死亡結(jié)點(diǎn)問(wèn)題解決!

后續(xù)我們把Patch提交到Hadoop社區(qū)HDFS-5341,其中蹩腳的英語(yǔ)語(yǔ)法請(qǐng)大家無(wú)視。

原文地址：解決HDFS磁盤掃描導(dǎo)致死亡結(jié)點(diǎn)的問(wèn)題, 感謝原作者分享。

聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com