• <fieldset id="8imwq"><menu id="8imwq"></menu></fieldset>
  • <bdo id="8imwq"><input id="8imwq"></input></bdo>
    最新文章專題視頻專題問答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還是可以讀取到數據塊的。所以,死亡結點的問題對線上業務沒有造成影響。當時,還有其它優先級更高的事情,所以,問題轉為觀察狀態。

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

    現象總結

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

    首先知道,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
    主站蜘蛛池模板: 99在线热播精品免费99热| 91精品国产自产在线观看永久| 日韩精品无码Av一区二区| 99精品国产丝袜在线拍国语 | 杨幂国产精品福利在线观看| 久久综合久久自在自线精品自| 亚洲嫩草影院久久精品| 国产精品毛片无遮挡| 亚洲精品你懂的在线观看| 鲸鱼传媒绿头鱼实验室之炮机测评日韩精品一级毛 | 天天视频国产精品| 99久久亚洲综合精品网站| 91精品国产高清久久久久久io | 中文字幕精品视频在线| 国内精品免费久久影院| 五月花精品视频在线观看| 国产精品免费福利久久| 亚洲AV永久无码精品一百度影院| 免费看污污的网站欧美国产精品不卡在线观看| 欧美亚洲国产精品第一页| 99精品国产一区二区三区2021| 老司机午夜精品视频资源| 中文字幕精品久久| 四虎影视永久在线精品免费| 亚洲国产精品一区二区久久| 国产成人精品无码片区在线观看| 亚洲动漫精品无码av天堂| 最新国产精品无码| 香蕉99久久国产综合精品宅男自| 久久se精品一区精品二区国产 | 精品无码国产污污污免费网站| 亚洲午夜精品久久久久久app | 青青青青久久精品国产| 精品视频在线免费观看| 国产精品爽黄69天堂a| 国产亚洲美女精品久久久久狼| 69久久夜色精品国产69| 国产精品午夜福利在线无码| 国内精品久久久久久99蜜桃 | 骚片AV蜜桃精品一区| 欧美在线精品一区二区三区|