本文根據阿里李鈺老師在中國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版本有哪些必須的準備以及線上升級操作有哪些注意事項。
閱讀更多 oscube 的文章
