HBase性能調優方法

　　因官方Book Performance Tuning部分章節沒有按配置項進行索引，不能達到快速查閱的效果。所以我以配置項驅動，重新整理了原文，并補充一些自己的理解，如有錯誤，歡迎指正。

　　配置優化

　　zookeeper.session.timeout

　　默認值：3分鐘(180000ms)

　　說明：RegionServer與Zookeeper間的連接超時時間。當超時時間到后，ReigonServer會被Zookeeper從RS集群清單中移除，HMaster收到移除通知后，會對這臺server負責的regions重新balance，讓其他存活的RegionServer接管.

　　調優：

　　這個timeout決定了RegionServer是否能夠及時的failover。設置成1分鐘或更低，可以減少因等待超時而被延長的failover時間。

　　不過需要注意的是，對于一些Online應用，RegionServer的宕機到恢復時間本身就很短的(網絡閃斷，crash等故障，運維可快速介入)，如果調低timeout時間，會得不償失。因為當ReigonServer被正式從RS集群中移除時，HMaster就開始做balance了，當故障的RS快速恢復后，這個balance動作是毫無意義的，反而會使負載不均勻，給RS帶來更多負擔。

　　hbase.regionserver.handler.count

　　默認值：10

　　說明：RegionServer的請求處理IO線程數。

　　調優：

　　這個參數的調優與內存息息相關。

　　較少的IO線程，適用于處理單次請求內存消耗較高的Big PUT場景(大容量單次PUT或設置了較大cache的scan，均屬于Big PUT)或ReigonServer的內存比較緊張的場景。

　　較多的IO線程，適用于單次請求內存消耗低，TPS要求非常高的場景。

　　這里需要注意的是如果server的region數量很少，大量的請求都落在一個region上，因快速充滿memstore觸發flush導致的讀寫鎖會影響全局TPS，不是IO線程數越高越好。

　　壓測時，開啟Enabling RPC-level logging，可以同時監控每次請求的內存消耗和GC的狀況，最后通過多次壓測結果來合理調節IO線程數。

　　這里是一個案例 Hadoop and HBase Optimization for Read Intensive Search Applications，作者在SSD的機器上設置IO線程數為100，僅供參考。

　　hbase.hregion.max.filesize

　　默認值：256M

　　說明：在當前ReigonServer上單個Reigon的大小，單個Region超過指定值時，這個Region會被自動split成更小的region。

　　調優：

　　小region對split和compaction友好，因為拆分region或compact小region里的storefile速度很快，內存占用低。缺點是split和compaction會很頻繁。

　　特別是數量較多的小region不停地split, compaction，會使響應時間波動很大，region數量太多不僅給管理上帶來麻煩，甚至引發一些Hbase的bug。

　　一般512以下的都算小region。

　　大region，則不太適合經常split和compaction，因為做一次compact和split會產生較長時間的停頓，對應用的讀寫性能沖擊非常大。此外，大region意味著較大的storefile，compaction時對內存也是一個挑戰。

　　當然，大region還是有其用武之地，你只要在某個訪問量低峰的時間點統一做compact和split，大region就可以發揮優勢了，畢竟它能保證絕大多數時間平穩的讀寫性能。

　　既然split和compaction如此影響性能，有沒有辦法去掉?

　　compaction是無法避免的，split倒是可以從自動調整為手動。

　　只要通過將這個參數值調大到某個很難達到的值，比如100G，就可以間接禁用自動split(RegionServer不會對未到達100G的region做split)。

　　再配合RegionSplitter這個工具，在需要split時，手動split。

　　手動split在靈活性和穩定性上比起自動split要高很多，相反，管理成本增加不多，比較推薦online實時系統使用。

　　內存方面，小region在設置memstore的大小值上比較靈活，大region則過大過小都不行，過大會導致flush時app的IO wait增高，過小則因store file過多讀性能降低。

　　hbase.regionserver.global.memstore.upperLimit/lowerLimit

　　默認值：0.4/0.35

　　upperlimit說明：hbase.hregion.memstore.flush.size 這個參數的作用是 當單個memstore達到指定值時，flush該memstore。但是，一臺ReigonServer可能有成百上千個memstore，每個memstore也許未達到flush.size，jvm的heap就不夠用了。該參數就是為了限制memstores占用的總內存。

　　當ReigonServer內所有的memstore所占用的內存綜合達到heap的40%時，HBase會強制block所有的更新并flush這些memstore以釋放所有memstore占用的內存。

　　lowerLimit說明： 同upperLimit，只不過當全局memstore的內存達到35%時，它不會flush所有的memstore，它會找一些內存占用較大的memstore，個別flush，當然更新還是會被block。lowerLimit算是一個在全局flush前的補救措施?？梢韵胂笠幌?，如果memstore需要在一段時間內全部flush，且這段時間內無法接受寫請求，對HBase集群的性能影響是很大的。

　　調優：這是一個Heap內存保護參數，默認值已經能適用大多數場景。它的調整一般是為了配合某些專屬優化，比如讀密集型應用，將讀緩存開大，降低該值，騰出更多內存給其他模塊使用。

　　這個參數會給使用者帶來什么影響?

　　比如，10G內存，100個region，每個memstore 64M，假設每個region只有一個memstore，那么當100個memstore平均占用到50%左右時，就會達到lowerLimit的限制。假設此時，其他memstore同樣有很多的寫請求進來。在那些大的region未flush完，就可能又超過了upperlimit，則所有region都會被block，開始觸發全局flush。

　　hfile.block.cache.size

　　默認值：0.2

　　說明：storefile的讀緩存占用Heap的大小百分比，0.2表示20%。該值直接影響數據讀的性能。

　　調優：當然是越大越好，如果讀比寫少，開到0.4-0.5也沒問題。如果讀寫較均衡，0.3左右。如果寫比讀多，果斷默認吧。設置這個值的時候，你同時要參考 hbase.regionserver.global.memstore.upperLimit ，該值是memstore占heap的最大百分比，兩個參數一個影響讀，一個影響寫。如果兩值加起來超過80-90%，會有OOM的風險，謹慎設置。

原文轉自：http://kenwublog.com/hbase-performance-tuning