基於生產環境實踐與自動化測試平台，對 HBase 純隨機讀/寫進行系統性壓測，記錄硬體配置、關鍵參數、效能數據與核心瓶頸分析，為 HBase 叢集容量規劃與調優提供實戰參考。
# RegionServer
-Xms16g -Xmx16g -Xmn2g -XX:SurvivorRatio=2 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=85
# DataNode
-Xms2g -Xmx2g
hbase.replication=false
hbase.balancer.period=1200000
hfile.block.cache.size=0.4 # 隨機讀 20% 命中場景設 0.01
hbase.regionserver.global.memstore.upperLimit=0.35
hbase.hregion.memstore.block.multiplier=8
hbase.server.thread.wakefrequency=100
hbase.regionserver.handler.count=300
hbase.master.distributed.log.splitting=false
hbase.regionserver.hlog.splitlog.writer.threads=3
hbase.hregion.max.filesize=1073741824
hbase.hstore.blockingStoreFiles=20
hbase.hregion.memstore.flush.size=134217728
hbase.client.retries.number=11
hbase.client.pause=20
hbase.ipc.client.tcpnodelay=true
ipc.ping.interval=3000
最佳點：客戶端 250 線程 → 平均延遲 ~6ms，TPS ~7.5k。
split file size 與 memstore flush size 緩解。寫速度核心影響因子：請求分佈均衡性、Blocking Update/Delaying Flush 是否出現、HLog 數量、DataNode 數量、Split File Size。
最佳點：Cache 命中率 90%、客戶端 250 線程 → 延遲與 TPS 表現優異。
讀速度核心影響因子：請求分佈均衡性、StoreFile 數量、BloomFilter 開啟狀態、Cache 大小與命中率。
根據最近生產環境使用的經驗，更多的項目的采用，以及采用了更加自動的測試平台，對HBase做了更多的場景的測試，在這篇blog中來分享下純粹的隨機寫和隨機讀的性能數據，同時也分享下我們調整過後的參數。
測試環境說明：
1、Region Server： 5台，12塊1T SATA盤(7200 RPM)，No Raid，物理內存24G，CPU型號為E5620；
啟動參數為：-Xms16g -Xmx16g -Xmn2g -XX:SurvivorRatio=2 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=85
2、Data Node：35台，和Region Server同樣的硬件配置，啟動參數上-Xms2g -Xmx2g，未設置-Xmn；
服務端參數：
hbase.replication false
hbase.balancer.period 1200000
hfile.block.cache.size 0.4，隨機讀20%命中場景使用0.01
hbase.regionserver.global.memstore.upperLimit 0.35
hbase.hregion.memstore.block.multiplier 8
hbase.server.thread.wakefrequency 100
hbase.regionserver.handler.count 300
hbase.master.distributed.log.splitting false
hbase.regionserver.hlog.splitlog.writer.threads 3
hbase.hregion.max.filesize 1073741824
hbase.hstore.blockingStoreFiles 20
hbase.hregion.memstore.flush.size 134217728
客戶端參數：
hbase.client.retries.number 11
hbase.client.pause 20
hbase.ipc.client.tcpnodelay true
ipc.ping.interval 3000
最終隨機寫的測試性能結果如下（點開可看大圖）：
從寫的測試來看，可以看到，當客戶端線程數在250左右時，此時的響應時間在6ms左右，tps在7.5k左右，差不多是比較好的一個狀態。
在隨機寫的測試中，以及我們的一些項目的測試中，看到的一些現象和問題：
1、隨著單台機器的region數變多了，tps下降的比較明顯，team的同事做了一個改進，保障了隨著region數的增多，tps基本不會有太多的下降，具體請見同事的這篇blog；
2、當hbase.regionserver.handler.count為100（默認為10，更正常了）時，壓力大的情況下差不多100個線程都會BLOCKED，增加到300後差不多足夠了，此時tps也到達瓶頸了；
3、當datanode數量比較少時，會導致寫tps比較低，原因是此時compact會消耗掉太多的網絡IO；
4、當寫采用gz壓縮時，會造成堆外內存洩露，具體請參見同事的這篇blog；
5、在壓力增大、region數增多的情況下，split和flush會對寫的平穩性造成比較大的影響，而通常內存是夠用的，因此可以調整split file size和memstore flush size，這個要根據場景來決定是否可調整。
對寫的速度影響比較大的因素主要是：請求次數的分布均衡、是否出現Blocking Update或Delaying flush、HLog數量、DataNode數量、Split File Size。
隨機讀的測試性能結果如下（點開可看大圖）：
從讀的測試來看，可以看到，讀的tps隨cache命中率降低會下降的比較厲害，命中率為90%時、客戶端線程數為250時，此時的響應時間和tps是比較不錯的狀況。
在隨機讀的測試中，以及我們的一些項目的測試中，看到的一些現象和問題：
1、隨機讀的tps隨著命中率下降，下降的有點太快，具體原因還在查找和分析中；
2、當命中率很低時，讀bloomfilter的索引信息需要耗費掉比較多的時間，主要原因是bloomfilter的索引信息並沒有在cache優先級中占優，這是一個可以改進的點。
對讀的速度影響比較大的因素主要是：請求次數的分布均衡、StoreFile數量、BloomFilter是否打開、Cache大小以及命中率。
ps: 強烈推薦同事的blog，其中記錄了很多我們對HBase的改進，以及我們在運維HBase項目時碰到的各種奇怪、詭異的問題。
