熱門:瘦小腿瘦小腿瘦小腿

  1. 首頁
  2. 科技日報
  3. 科技

回顧·HBase in Practice-效能、監控及問題解決

  • 小白兔

  • 2018-10-12 18:16:32

來源:HBase技術社群

本文根據阿里李鈺老師在中國HBase技術社群第二屆MeetUp:“HBase技術解析及應用實踐”中分享的《HBase in Practice-效能、監控及問題解決》編輯整理而成,在未改變原意的基礎上稍做整理。

李鈺老師

今天分享主要從兩個大的部分介紹,第一部分會講一些效能優化的知識,針對IO的效能優化,不同版本值得注意的效能問題/優化;第二部分將監控應該關注哪些指標以及在日誌裡面如何做問題排查。

首先講一下針對IO效能優化,每個廠商IO硬體效能都不一樣,針對不同的硬體,需要利用的功能和注意的問題也不一樣。如HDD,它的IO能力比較弱,很容易打爆,如果在雲上應用HBase,有很多不同的硬碟可以使用。在HDD架設HBase要避免磁碟被打爆,HBase提供了很多方法,第一個就是Compaction限流,基本思想就是限制它每秒能寫出的資料量,在1.1.0版本以上才能使用,對於1.3.0版本分界線以上以下配置不同,具體配置如上圖所示。你可以設定其吞吐 的上限和下限,也可以設定平峰期的限制。我們進行限流肯定一般是在高峰期,在平峰期沒有必要,也或者平峰期你有沒有其他的應用,有時也會跑一些其他的應用,如spark等。Flush限流是在1.3.0版本以上支援的,其實主要的IO來源就是Compaction和Flush,配置與Compaction比較像。值得注意的是限流不能過低,如果過低Compaction的Hfile數就降不下來,block stokenfile預設值是20,如果超過20,flush就會delay,記憶體會膨脹,如果膨脹超過一定區域就會block update,會出現寫入延遲阻塞。因此兩者限流需要依據實際限流,不能限流過低。

另外一個在HDD上比較適合是Per-CF Flush,在1.1.0版本以上就支援,預設配置是flush all stores,當main Store的大小達到設定閥值,就會將所有的CF都flush出來。但是有些CF檔案比較小,會出現浪費io,另外刷出很多小檔案需要compaction,對磁碟也會有影響。因此出現了HBase available,在1.1.0版本以上可以用,從1.1.0-2.0實質是設定了一個下限,如果CF檔案在main Store時超過16M就將其flush,沒有超過就不flush。後續在社群基礎上做了改變,將預設值改為flush大小除以CF的個數,這樣的問題有可能出現CF過多,因此也會有下限值控制,也是16M。使用這個功能也需要注意,開啟這個功能有很多資料是不flush,但是如果出現故障,replay的資料會變多,在HBase中有個引數optional flush internal,可以設定過多長時間強制flush一次,還有一個flush prechanges,就是有多少change就flush一次;一個預設值是1小時,後面是3千萬。

第三個方案是多盤,多盤在社群1.0版本就有多log的功能。如果在自己的機器上,伺服器都是12塊硬碟,如果用一個write tacklog,HDFS是三個副本,雖然能將吞吐打滿,三個副本需要三個盤,無法使用完,IO能力沒充分利用。解決方式就是用多個write tacklog,一個region server配置4個hlog,測試效能會提升20%。版本低於1.2.0:replication存在問題, hbase.wal.provider ->multiwall,hbase.wal.regiongrouping.strategy -> bounded ,根據盤數設定hbase.wal.regiongrouping.numgroups。需要注意寫多少Hlog是依據你的盤確定,IO能力是否充足。

SSD在HBase裡面也有很好的支援,SSD對效能的優化分為兩個部分,一方面是讀,另一方面是寫。影響寫的效能就是write height log的寫,SSD能很大的降低其響應時間,在用SSD時也可以用Multi WAL,其寫入效能比單WAL提升40%以上。從讀方面來說,在CF可以設定Storage Policy,但該功能在2.0版本上才有。對不同的CF設定不同的Storage Policy(wan SSD,all SSD),設定多CF的原因是資料的冷熱程度是不一樣的。Bulkload也需要支援Storage Policy配置,如果生成的檔案都是HDD,會影響讀取的效能。

SSD需要注意的是如果是Wan SSD需要允許HDFS client優先讀遠端SSD上的副本,但是未合入社群版本,需要手動backport。對於Hybrid,WAL策略可以是WAL SSD,對CF級別也可以是WAL SSD。值得注意的是SSD也需要開啟限流。Merge MVCCand SequenceId引發的效能問題:branch-1.0不要使用1.0.3以下版本,branch-1.1不要使用1.1.3以下版本。高負載下寫入效能瓶頸: 如果線上發現wait在WALKey#get Write Entry,建議升級到1.4.0以上版本,對ASYNC_WAL寫入效能提升尤其明顯 。在讀的效能,如果用的是Bucket Cache,在高併發讀取單key的效能問題,在1.2.0以上版本可以解決。如果遠端讀SSD,需要考慮網路開銷,Hybrid開銷尤其大。

接下來講一下問題排查,首先是RPC相關監控:Server響應時間,Server處理時間,請求排隊時間。Total Call Time記錄的是請求到達你的regionServer開始到server請求完結束,不包含傳送結果的時間。業務在請求,但是server處理也好,這種情況需要去業務debug客戶端網路是不是擁塞。Total Call Time肯定是等於ProcessCall Time+QueueCall Time,請求到達server是先進入一個佇列,如果heightlog不繁忙,QueueCall Time會很短,但是如果server很繁忙active handler數很滿,calltime會很長,請求是從隊列出來後處理。Active Handler 在1.4.0版本以前是沒有讀寫分離監控的。讀寫分離的好處就是Handler打滿到底是讀出問題還是寫出問題就可以很容易監控。RPC佇列長度也可以判斷機器是否出問題了,RPC連線數很高也是消耗系統資源。上圖是我們監控指標圖,如圖一峰值就可以推測這臺機器可能有點問題。

請求相關指標對debug很重要,Put請求latency,Get請求latency,Scan請求latency等這些都會監控。我想說明就是對latency監控,Hbase出問題到底是檔案系統出問題了還是regionServer出問題了,這個困擾了我們很久,因為底層會有一個檔案系統,檔案系統過肯定會受影響,因次對於put來說你要監控WAL sync latency,對於get要監控HDFS pread latency,Scan請求latency。對於HDFS pread latency需要1.4.0版本以上。如果發現Get請求latency很高,HDFS pread latency也很高,那麼基本確定HDFS陡了,至少可以定位問題。否則就必須定位999的regionserver一一排查。

第三個就是記憶體相關的指標,GC對於排查問題作用未必很大,但是可以監控整體情況。對於GC更多的是查GC日誌更有效果,pause Time Without GC不是程序GC導致的問題時,在1.4.0版本以上會發現一些日誌的,這個時候需要關注一些系統的指標,如記憶體整理,那麼你整個系統會停止,或者資源瓶頸或者CPU滿了都會導致程序堵塞。再一個就是對Block Cache/MemStore 的監控,如何監控Hfile數過多,一方面可以監控blockupdate的字元和頻率,另一方面是看MemStore數是否變大了。Block Cache在1.3.0版本以上可以區分data和meta命中率,meta block命中率一般都很高,訪問頻率也很高,如果不區分這個命中率有可能是假的。真實的data block命中率在65%,但是meta命中率基本是100%。

RegionServer單機指標,如果看到一個regionserver打滿了,需要看regionServer單機指標。如region大小,這個指標引起cache的命中率,get和寫運算元,看topN那些請求非常高,handler打滿,get時間非常高,可以查詢那個region訪問過多,有些情況是訪問值超過正常值導致的,因此可以通過表找到問題去解決。再一個就是compaction佇列長度和flush佇列長度。

如何發現stale的Region Server,如果出現壞盤,請求卡在IO上一直無法返回,響應時間相關指標無法捕捉,在total call time中無法體現。還有就是你的數值很好但是機器已經出問題,因為出問題的請求沒有彙報給server,另外如果機器資源耗盡,新的請求無法連線server,從響應時間等server metrics上也體現不出來。因此做了一個增強health check,定期向自己發請求並設定超時時間,失敗超過一定概率報警,有一個問題就是還沒有Upstreaming in progress,但後續會完成。其實會出現一個情況就是系統資源耗盡,但是已經啟動的執行緒可以執行,但是無法啟動新的執行緒,就是一臺機器已經不能服務,但是master還是可以服務。

接下來講一下日誌的排查,首先關於慢請求。如發現一個server的999時間很長,第一反應是登陸該臺regionServer檢視日誌,尤其是responsetooslow日誌,但是老版本是不會列印任何有關processingtime 、roll具體資訊的,因此會關注這兩個HBASE-16033/HBASE-16972 response Too Slow,會列印詳細資訊,前面一個jQuery是對普通請求,後面一個jQuery是對scan。經常會看到scan超時等這些資訊都是很重要的。branch-1.1要求1.1.8以上,branch-1.2要求1.2.5以上,或1.3.0以上版本。在自己的版本還做了一些事情,但是還未放到社群,會區分如果是慢請求,到底long process time還是long call Time,因為一個long process time會導致一系列的long call Time。如果不區分會看到很多response TooSlow,但是你並不知道出現的問題是什麼。當然還需要設定閾值,超過多長時間才算慢請求,我們是超過10秒才算慢請求,這個可以自己配置。如設定10秒其實8秒也不短,這時需要去region Server上解scandetail,去檢視handler執行緒wait在什麼地方,wait的地方出現了多少。

在Client端也有些日誌也是非常重要的,對於single請求列印很全,但是要注意batch,branch-1.1要求1.1.6以上,branch-1.2要求1.2.3以上,或1.3.0以上版本。在有慢請求時,去列印具體是哪個region,還有目前執行在哪個server上,或者在batch請求異常時列印異常的batch棧。客戶端還有其他好的機制,HBase客戶端是由backoff policy,就是通過regionServer的region load判斷是否需要sleep一段時間。後續有機會可以討論如何排查GC、記憶體洩漏等複雜問題,如何定位瘋狂訪問RS的問題客戶端應用,如何規避HDFS故障對HBase的影響,2.0黑科技在線上應用可能踩的坑,升級HBase版本有哪些必須的準備以及線上升級操作有哪些注意事項。

推薦您的文章

其他文章