<span id="mktg5"></span>

<i id="mktg5"><meter id="mktg5"></meter></i>

        <label id="mktg5"><meter id="mktg5"></meter></label>
        最新文章專題視頻專題問答1問答10問答100問答1000問答2000關鍵字專題1關鍵字專題50關鍵字專題500關鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關鍵字專題關鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
        問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
        當前位置: 首頁 - 科技 - 知識百科 - 正文

        解決HDFS磁盤掃描導致死亡結點的問題

        來源:懂視網 責編:小采 時間:2020-11-09 13:17:56
        文檔

        解決HDFS磁盤掃描導致死亡結點的問題

        解決HDFS磁盤掃描導致死亡結點的問題:在Hadoop集群從1.0升級到2.0之后,我們一直在解決很多很多的問題。在今年8月初,我們檢測到線上頻繁有機器變成死亡結點,一段時間后自動恢復。進入死亡結點狀態的DataNode將不能讀寫數據塊。我們觀察了一下日志,看到DataNode中打印出很多接受數據快傳輸的線
        推薦度:
        導讀解決HDFS磁盤掃描導致死亡結點的問題:在Hadoop集群從1.0升級到2.0之后,我們一直在解決很多很多的問題。在今年8月初,我們檢測到線上頻繁有機器變成死亡結點,一段時間后自動恢復。進入死亡結點狀態的DataNode將不能讀寫數據塊。我們觀察了一下日志,看到DataNode中打印出很多接受數據快傳輸的線

        在Hadoop集群從1.0升級到2.0之后,我們一直在解決很多很多的問題。在今年8月初,我們檢測到線上頻繁有機器變成死亡結點,一段時間后自動恢復。進入死亡結點狀態的DataNode將不能讀寫數據塊。我們觀察了一下日志,看到DataNode中打印出很多接受數據快傳輸的線

        在Hadoop集群從1.0升級到2.0之后,我們一直在解決很多很多的問題。在今年8月初,我們檢測到線上頻繁有機器變成死亡結點,一段時間后自動恢復。進入死亡結點狀態的DataNode將不能讀寫數據塊。我們觀察了一下日志,看到DataNode中打印出很多接受數據快傳輸的線程(DataXceiver),線程都是在Receiving的狀態,而沒有結束。估摸了一下在死亡結點發生的階段大約有300個左右的線程積累下來。但是,沒找到其它突破口。

        由于,HDFS的Client會自動重試。如果一個結點進入死亡結點,只要另外的數據塊的結點依然可讀,Client還是可以讀取到數據塊的。所以,死亡結點的問題對線上業務沒有造成影響。當時,還有其它優先級更高的事情,所以,問題轉為觀察狀態。

        然后終于在一次機房意外斷電,集群重啟之后,一個線上的作業報找不到數據塊。經日志確認,產生的原因是擁有這個數據塊副本的兩個機器同時進入死亡結點! 于是,問題轉入高優先級,優先解決。

        現象總結

      1. 出現死亡結點的機器集中在磁盤數量較多的機器。
      2. 死亡結點跟機器的CPU,內存或者網絡關系不大。
      3. 出現死亡結點的時候,DataNode有大量DataXceiver的線程積壓。
      4. 雖然,總體上機器出現死亡結點的時間比較分散。但是,單一的DataNode上出現死亡結點的間隔必然是6小時或者6小時的整數倍。
      5. 攻堅

        首先知道,DataNode進入死亡結點狀態是因為NameNode長期接收不到DataNode的心跳包,就會把DataNode歸入死亡結點。而DataNode的心跳線程是單獨一個線程。

        現象的最后一點,6小時的間隔,可謂是這個問題的突破點。在配置文件中找到6小時的間隔的工作有兩種:

        1. DataNode和NameNode的6小時一次的心跳報告。用于更新NameNode上的Block信息。
        2. DataNode每6小時一次的磁盤掃描。用于更新內存中的信息和磁盤中信息的不一致。

        根據兩者打印的日志和死亡結點發生的時間進行精確對比,發現后者的時間基本吻合。 然后,我們在集中查看磁盤掃描(DirectoryScanner)的代碼。

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

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

        第一步,主線程和線程池的線程都是Daemon線程。Daemon線程的默認優先級比較低。

        第二步,由于涉及到磁盤讀寫。如果,外部磁盤壓力大的時候,會拖慢整個進度。但是,整個過程沒有加鎖。不可能對其它線程產生影響。

        第四步,數據塊對比過程,為了阻止對blockMap的修改,整個過程針對DataSet對象加鎖(DataSet對象是DataNode中保存所有數據塊信息的內存對象)。

        那心跳進程為什么會使用DataSet的對象鎖? 我們寫了個小程序測試,在對DataSet加鎖的情況下,啟動心跳線程。發現心跳線程在獲取磁盤的可用空間的時候,需要獲得DataSet的鎖。

        于是,問題變得清晰了:在6小時一次的磁盤掃描中,由于DirectoryScanner長久占用了DataSet的鎖,導致心跳線程不能發出心跳包。DataNode進入死亡結點狀態。而問題頻發在磁盤較多的機器是因為,數據塊數量和對比的過程的耗時相關。那是什么原因導致DirectoryScanner長久占用了DataSet的鎖呢?

        我們觀察了加鎖部分的代碼,沒有找到磁盤操作。我們估摸了下,最多數據塊的機器也才80W左右各數據塊。如果是純內存操作,不可能占用鎖長達10分鐘甚至30分鐘之久。

        然后我們將懷疑的地方鎖定在主線程的Daemon屬性。因為,Daemon屬性的線程優先級較低,懷疑是主線程在多線程的情況下,分配不到CPU時間片。

        于是,我們作出第一個修改:將主線程改為普通線程的優先級。

        上線第二天,死亡結點現象還是出現,現象出現的時間相對來說是短了點,但還是不能解決問題。

        于是,我們開了個大招:針對死亡結點頻發的結點,加上一個每分鐘打印一次DataNode的jstack的腳本。

        終于我們捕獲了在死亡結點發生時候的幾個堆棧。經過對比分析,得出的結論是:

        (呵呵)數據塊對比過程中,有一個使用Java的File對象的獲取文件長度的getlength方法。而這個方法是直接調用一個native方法,獲取磁盤上文件的長度。

        當初我們就猜想,加鎖部分是否有磁盤的IO操作。因為IO操作的快慢,會受到當時的機器狀態影響很大。不得不說,這個位置太隱蔽了。看了很久都沒發現,還好有jstack截獲出來。

        總結

        6小時一次的DirectoryScanner在數據塊對比過程中,會對DataSet加鎖。如果,機器的磁盤壓力很高的情況下,對比過程中的磁盤操作十分耗時。導致DirectoryScanner長期持有DataSet的鎖,阻塞心跳線程和所有的DataXceiver的線程。DataNode變成死亡結點。一段時間后,對比過程結束。DataSet鎖釋放,DataNode回歸正常工作。

        解決

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

        部署到線上后,數據對比時間降低到2秒左右。至此,死亡結點問題解決!

        后續我們把Patch提交到Hadoop社區HDFS-5341,其中蹩腳的英語語法請大家無視。

        聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

        文檔

        解決HDFS磁盤掃描導致死亡結點的問題

        解決HDFS磁盤掃描導致死亡結點的問題:在Hadoop集群從1.0升級到2.0之后,我們一直在解決很多很多的問題。在今年8月初,我們檢測到線上頻繁有機器變成死亡結點,一段時間后自動恢復。進入死亡結點狀態的DataNode將不能讀寫數據塊。我們觀察了一下日志,看到DataNode中打印出很多接受數據快傳輸的線
        推薦度:
        標簽: 掃描 解決 問題
        • 熱門焦點

        最新推薦

        猜你喜歡

        熱門推薦

        專題
        Top
        主站蜘蛛池模板: 国产成人人综合亚洲欧美丁香花 | 91在线精品亚洲一区二区| 一级成人a做片免费| 亚洲日本一区二区一本一道| 杨幂最新免费特级毛片| 亚洲精品久久久www| 国产精品视频全国免费观看| 亚洲欧洲无码AV电影在线观看| 久久av免费天堂小草播放| 亚洲小说区图片区另类春色| 精品一区二区三区免费观看| 亚洲AV无码乱码国产麻豆| 在线观看片免费人成视频无码| 亚洲AV午夜成人片| 99久久国产热无码精品免费| 中文字幕亚洲精品无码| 国产无遮挡吃胸膜奶免费看 | 国产精品偷伦视频观看免费| 亚洲国产第一站精品蜜芽| 免费无码一区二区三区| 亚洲专区一路线二| 免费国产a国产片高清| 一级黄色毛片免费看| 久久久亚洲裙底偷窥综合| 大学生一级毛片免费看| 羞羞漫画在线成人漫画阅读免费| 国产精品亚洲玖玖玖在线观看| 热久久这里是精品6免费观看| 亚洲日本香蕉视频| 国产一区二区三区免费在线观看| 久久久久久久国产免费看| 亚洲欧洲一区二区| 国产成人精品123区免费视频| 国产精品免费视频观看拍拍 | 久久久久久A亚洲欧洲AV冫| 99精品视频在线免费观看| 亚洲日本一线产区和二线产区对比| 亚洲国产精品嫩草影院久久 | 永久免费看bbb| 免费看少妇高潮成人片| 亚洲五月综合网色九月色|