上一篇文章《公司HBase基準性能測試之準備篇》中詳細介紹了本次性能測試的基本準備情況，包括測試集群架構、單臺機器軟硬件配置、測試工具以及測試方法等，在此基礎上本篇文章主要介紹HBase在各種測試場景下的性能指標（主要包括單次請求平均延遲和系統吞吐量）以及對應的資源利用情況，并對各種測試結果進行分析。
測試結果
單條記錄插入
測試參數
總記錄數為10億，分為128個region，均勻分布在4臺region server上；插入操作執行2千萬次；插入請求分布遵從zipfian分布；
測試結果
資源使用情況
上圖為單臺RegionServer的帶寬使用曲線圖（資源使用情況中只列出和本次測試相關的資源曲線圖，后面相關資源使用情況類似），本次測試線程為1000的情況下帶寬基本維持在100M左右，對于百兆網卡來說基本上已經打滿。
結果分析
1. 吞吐量曲線分析：線程數在10~500的情況下，隨著線程數的增加，系統吞吐量會不斷升高；之后線程數再增加，系統吞吐量基本上不再變化。結合圖3帶寬資源使用曲線圖可以看出，當線程數增加到一定程度，系統帶寬資源基本耗盡，系統吞吐量就不再會增加。可見，HBase寫操作是一個帶寬敏感型操作，當帶寬資源bound后，寫入吞吐量基本就會穩定。
2. 寫入延遲曲線分析：隨著線程數的不斷增加，寫入延遲也會不斷增大。這是因為寫入線程過多，導致CPU資源調度頻繁，單個線程分配到的CPU資源會不斷降低；另一方面由于線程之間可能會存在互斥操作導致線程阻塞；這些因素都會導致寫入延遲不斷增大。
建議
根據曲線顯示，500線程以內的寫入延遲并不大于10ms，而此時吞吐量基本最大，因此如果是單純寫入的話500線程寫入會是一個比較合適的選擇。
單純查詢
測試參數
總記錄數為10億，分為128個region，均勻分布在4臺region server上；查詢操作執行2千萬次；查詢請求分布遵從zipfian分布；
測試結果
資源使用情況
圖5為線程數在1000時IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。圖6為線程數在1000時系統負載曲線圖，圖中load1曲線表示在最近一分鐘內的平均負載，load5表示最近五分鐘內的平均負載。最近5分鐘的負責達到了50左右，對于32核系統來說，表示此時系統負載很高，已經遠遠超負荷運行。
結果分析
1. 吞吐量曲線分析：線程數在10~500的情況下，隨著線程數的增加，系統吞吐量會不斷升高；之后線程數再增加，系統吞吐量基本上不再變化。結合圖5、圖6系統資源使用曲線圖可以看出，當線程數增加到一定程度，系統IO資源基本達到上限，系統負載也特別高。IO利用率達到100%是因為大量的讀操作都需要從磁盤查找數據，系統負載很高是因為HBase需要對查找的數據進行解壓縮操作，解壓縮操作需要耗費大量CPU資源。這兩個因素結合導致系統吞吐量就不再隨著線程數增肌而增加。可見，HBase讀操作是一個IO/CPU敏感型操作，當IO或者CPU資源bound后，讀取吞吐量基本就會穩定不變。
2. 延遲曲線分析：隨著線程數的不斷增加，讀取延遲也會不斷增大。這是因為讀取線程過多，導致CPU資源調度頻繁，單個線程分配到的CPU資源會不斷降低；另一方面由于線程之間可能會存在互斥操作導致線程阻塞；這些因素都會導致寫入延遲不斷增大。和寫入延遲相比，讀取延遲會更大，是因為讀取涉及IO操作，IO本身就是一個耗時操作，導致延遲更高。
建議
根據曲線顯示，500線程以內的讀取延遲并不大于20ms，而此時吞吐量基本最大，因此如果是單純讀取的話500線程讀取會是一個比較合適的選擇。
Range掃描查詢
測試參數
總記錄數為10億，分為128個region，均勻分布在4臺region server上；scan操作執行一千兩百萬次，請求分布遵從zipfian分布； scan最大長度為100條記錄， scan長度隨機分布且遵從uniform分布；
測試結果
資源使用情況
圖8為線程數在1000時IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。圖9為線程數在1000時帶寬資源使用曲線圖，圖中帶寬資源基本也已經達到上限。
結果分析
1. 吞吐量曲線分析：線程數在10~500的情況下，隨著線程數的增加，系統吞吐量會不斷升高；之后線程數再增加，系統吞吐量基本上不再變化。結合圖8 、圖9資源使用曲線圖可以看出，當線程數增加到一定程度，系統IO資源基本達到上限，帶寬也基本達到上限。IO利用率達到100%是因為大量的讀操作都需要從磁盤查找數據，而帶寬負載很高是因為每次scan操作最多可以獲取50Kbyte數據，TPS太高會導致數據量很大，因而帶寬負載很高。兩者結合導致系統吞吐量就不再隨著線程數增大會增大。可見，scan操作是一個IO/帶寬敏感型操作，當IO或者帶寬資源bound后，scan吞吐量基本就會穩定不變。
2. 延遲曲線分析：隨著線程數的不斷增加，讀取延遲也會不斷增大。這是因為讀取線程過多，導致CPU資源調度頻繁，單個線程分配到的CPU資源會不斷降低；另一方面由于線程之間可能會存在互斥操作導致線程阻塞；這些因素都會導致寫入延遲不斷增大。和寫入延遲以及單次隨機查找相比，讀取延遲會更大，是因為scan操作會涉及多次IO操作，IO本身就是一個耗時操作，因此會導致延遲更高。
建議
根據圖表顯示，用戶可以根據業務實際情況選擇100~500之間的線程數來執行scan操作。
查詢插入平衡
測試參數
總記錄數為10億，分為128個region，均勻分布在4臺region server上；查詢插入操作共執行8千萬次；查詢請求分布遵從zipfian分布；
測試結果
資源使用情況
圖11為線程數在1000時系統IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。圖12為線程數在1000時系統負載曲線圖，圖中顯示CPU負載資源達到了40+，對于只有32核的系統來說，已經遠遠超負荷工作了。
結果分析
1. 吞吐量曲線分析：線程數在10~500的情況下，隨著線程數的增加，系統吞吐量會不斷升高；之后線程數再增加，系統吞吐量變化就比較緩慢。結合圖11、圖12系統資源使用曲線圖可以看出，當線程數增加到一定程度，系統IO資源基本達到上限，帶寬也基本達到上限。IO利用率達到100%是因為大量的讀操作都需要從磁盤查找數據，而系統負載很高是因為大量讀取操作需要進行解壓縮操作，而且線程數很大本身就需要更多CPU資源。因此導致系統吞吐量就不再會增加。可見，查詢插入平衡場景下，當IO或者CPU資源bound后，系統吞吐量基本就會穩定不變。
2. 延遲曲線分析：隨著線程數的不斷增加，讀取延遲也會不斷增大。這是因為讀取線程過多，導致CPU資源調度頻繁，單個線程分配到的CPU資源會不斷降低；另一方面由于線程之間可能會存在互斥操作導致線程阻塞；這些因素都會導致寫入延遲不斷增大。圖中讀延遲大于寫延遲是因為讀取操作涉及到IO操作，比較耗時。
建議
根據圖表顯示，在查詢插入平衡場景下用戶可以根據業務實際情況選擇100~500之間的線程數。
插入為主
測試參數
總記錄數為10億，分為128個region，均勻分布在4臺region server上；查詢插入操作共執行4千萬次；查詢請求分布遵從latest分布；
測試結果
資源使用情況
圖15為線程數在1000時系統帶寬使用曲線圖，圖中系統帶寬資源基本到達上限，而總體IO利用率還比較低。
結果分析
1. 曲線分析：線程數在10~500的情況下，隨著線程數的增加，系統吞吐量會不斷升高；之后線程數再增加，系統吞吐量基本上不再變化。結合圖14帶寬資源使用曲線圖可以看出，當線程數增加到一定程度，系統帶寬資源基本耗盡，系統吞吐量就不再會增加。基本同單條記錄插入場景相同。
2. 寫入延遲曲線分析： 基本同單條記錄插入場景。
建議
根據圖表顯示，插入為主的場景下用戶可以根據業務實際情況選擇500左右的線程數來執行。
查詢為主
測試參數
總記錄數為10億，分為128個region，均勻分布在4臺region server上；查詢插入操作共執行4千萬次；查詢請求分布遵從zipfian分布；
測試結果
資源使用情況
圖17為線程數在1000時IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經達到使用上限。
結果分析
基本分析見單純查詢一節，原理類似。
建議
根據圖表顯示，查詢為主的場景下用戶可以根據業務實際情況選擇100~500之間的線程數來執行。
Increment自增
測試參數
1億條數據，分成16個Region，分布在4臺RegionServer上；操作次數為100萬次；
測試結果
結果分析
1. 線程數增加，Increment操作的吞吐量會不斷增加，線程數到達100個左右時，吞吐量會達到頂峰（23785 ops/sec），之后再增加線程數，吞吐量基本維持不變;
2. 隨著線程數增加，Increment操作的平均延遲會不斷增加。線程數在100以下，平均延時都在4ms以內；
建議
根據圖表顯示，查詢為主的場景下用戶可以根據業務實際情況選擇100~500之間的線程數來執行。
測試結果總結
根據以上測試結果和資源利用情況可以得出如下幾點：
1. 寫性能：集群吞吐量最大可以達到70000+ ops/sec，延遲在幾個毫秒左右。網絡帶寬是主要瓶頸，如果將千兆網卡換成萬兆網卡，吞吐量還可以繼續增加，甚至達到目前吞吐量的兩倍。
2. 讀性能：很多人對HBase的印象可能都是寫性能很好、讀性能很差，但實際上HBase的讀性能遠遠超過大家的預期。集群吞吐量最大可以達到26000+，單臺吞吐量可以達到8000+左右，延遲在幾毫秒～20毫秒左右。IO和CPU是主要瓶頸。
3. Range 掃描性能：集群吞吐量最大可以達到14000左右，系統平均延遲在幾毫秒～60毫秒之間（線程數越多，延遲越大）；其中IO和網絡帶寬是主要瓶頸。
測試注意事項
1. 需要關注是否是全內存測試，全內存測試和非全內存測試結果相差會比較大。參考線上實際數據情況，本次測試采用非全內存讀測試。是否是全內存讀取決于總數據量大小、集群Jvm內存大小、Block Cache占比、訪問分布是否是熱點訪問這四者，在JVM內存大小以及Block Cache占比不變的情況下，可以增大總數據量大小或者修改訪問分布；
2. 測試客戶端是否存在瓶頸。HBase測試某些場景特別耗費帶寬資源，如果單個客戶端進行測試很可能會因為客戶端帶寬被耗盡導致無法測出實際服務器集群性能。本次測試使用6個客戶端并發進行測試。
3. 單條記錄大小對測試的影響。單條記錄設置太大，會導致并發插入操作占用大量帶寬資源進而性能產生瓶頸。而設置太小，測試出來的TPS峰值會比較大，和線上實際數據不符。本次測試單條數據大小設置為50M，基本和實際情況相符。
本文章為作者原創
🈲禁止🈲
其他公眾賬號轉載，若有轉載，請標明出處
文章列表
留言列表
