因官方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根據故障機器記錄的WAL日誌進行恢復）。當故障的RS在人工介入恢復後，這個balance動作是毫無意義的，反而會使負載不均勻，給RS帶來更多負擔。特別是那些固定分配regions的場景。

hbase.zookeeper.quorum
預設值：localhost
說明：hbase所依賴的zookeeper部署
調優：
部署的zookeeper越多，可靠性就越高，但是部署只能部署奇數個，主要為了便於選出leader。最好給每個zookeeper 1G的記憶體和獨立的磁碟，可以確保高效能。hbase.zookeeper.property.dataDir可以修改zookeeper儲存資料的路徑。

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執行緒數越高越好。
壓測時，開啟

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，既能順利完成split和compaction，又能保證絕大多數時間平穩的讀寫效能。

既然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 這個引數的作用是當單個Region內所有的memstore大小總和超過指定值時，flush該region的所有memstore。RegionServer的flush是通過將請求新增一個佇列，模擬生產消費模式來非同步處理的。那這裡就有一個問題，當佇列來不及消費，產生大量積壓請求時，可能會導致記憶體陡增，最壞的情況是觸發OOM。
這個引數的作用是防止記憶體佔用過大，當ReigonServer內所有region的memstores所佔用記憶體總和達到heap的40%時，HBase會強制block所有的更新並flush這些region以釋放所有memstore佔用的記憶體。
lowerLimit說明： 同upperLimit，只不過lowerLimit在所有region的memstores所佔用記憶體達到Heap的35%時，不flush所有的memstore。它會找一個memstore記憶體佔用最大的region，做個別flush，此時寫更新還是會被block。lowerLimit算是一個在所有region強制flush導致效能降低前的補救措施。在日誌中，表現為 “** Flush thread woke up with memory above low water.”
調優：這是一個Heap記憶體保護引數，預設值已經能適用大多數場景。
引數調整會影響讀寫，如果寫的壓力大導致經常超過這個閥值，則調小讀快取hfile.block.cache.size增大該閥值，或者Heap餘量較多時，不修改讀快取大小。
如果在高壓情況下，也沒超過這個閥值，那麼建議你適當調小這個閥值再做壓測，確保觸發次數不要太多，然後還有較多Heap餘量的時候，調大hfile.block.cache.size提高讀效能。
還有一種可能性是?hbase.hregion.memstore.flush.size保持不變，但RS維護了過多的region，要知道 region數量直接影響佔用記憶體的大小。

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的風險，謹慎設定。

hbase.hstore.blockingStoreFiles
預設值：7
說明：在flush時，當一個region中的Store（Coulmn Family）內有超過7個storefile時，則block所有的寫請求進行compaction，以減少storefile數量。
調優：block寫請求會嚴重影響當前regionServer的響應時間，但過多的storefile也會影響讀效能。從實際應用來看，為了獲取較平滑的響應時間，可將值設為無限大。如果能容忍響應時間出現較大的波峰波谷，那麼預設或根據自身場景調整即可。

hbase.hregion.memstore.block.multiplier
預設值：2
說明：當一個region裡的memstore佔用記憶體大小超過hbase.hregion.memstore.flush.size兩倍的大小時，block該region的所有請求，進行flush，釋放記憶體。
雖然我們設定了region所佔用的memstores總記憶體大小，比如64M，但想象一下，在最後63.9M的時候，我Put了一個200M的資料，此時memstore的大小會瞬間暴漲到超過預期的hbase.hregion.memstore.flush.size的幾倍。這個引數的作用是當memstore的大小增至超過hbase.hregion.memstore.flush.size 2倍時，block所有請求，遏制風險進一步擴大。
調優： 這個引數的預設值還是比較靠譜的。如果你預估你的正常應用場景（不包括異常）不會出現突發寫或寫的量可控，那麼保持預設值即可。如果正常情況下，你的寫請求量就會經常暴長到正常的幾倍，那麼你應該調大這個倍數並調整其他引數值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit，以預留更多記憶體，防止HBase server OOM。

hbase.client.scanner.caching
預設值：1
說明：scanner呼叫next方法一次獲取的資料條數
調優：少的RPC是提高hbase執行效率的一種方法，理論上一次性獲取越多資料就會越少的RPC，也就越高效。但是記憶體是最大的障礙。設定這個值的時候要選擇合適的大小，一面一次性獲取過多資料佔用過多記憶體，造成其他程式使用記憶體過少。或者造成程式超時等錯誤（這個超時與hbase.regionserver.lease.period相關）。

hbase.regionserver.lease.period
預設值：60000
說明：客戶端租用HRegion server 期限，即超時閥值。
調優：
這個配合hbase.client.scanner.caching使用，如果記憶體夠大，但是取出較多資料後計算過程較長，可能超過這個閾值，適當可設定較長的響應時間以防被認為宕機。