Hbase讀寫效能測試調優

日期	版本	修訂	審批	修訂說明
2016.9.23	1.0	章鑫	初始版本

1 前言

本篇文章主要講的是hbase讀寫效能調優過程中遇到的一些技巧和配置項的修改，對於hbase本身的原理和框架不會做太多的介紹。該文件中涉及到ycsb配置和使用方面的內容需要結合ycsb工具使用文件閱讀理解。

2 配置

2.1 叢集配置

[[email protected] ~]#uname -a

Linux node1.dcom 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[[email protected] ~]# top

top - 10:02:40 up 51 days, 12:39, 11 users, load average: 1.42, 1.23, 1.04

Tasks: 414 total, 1 running, 413 sleeping, 0 stopped, 0 zombie

%Cpu(s): 1.6 us, 0.4 sy, 0.0 ni, 97.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65772144 total, 23124796 free, 8079632 used, 34567716 buff/cache

KiB Swap: 0 total, 0 free, 0 used. 56828368 avail Mem

[[email protected] ~]# free -m #64G記憶體

total used free shared buff/cache available

Mem: 64230 7899 23391 475 32939 55486

Swap: 0 0 0

[[email protected] ~]# df -Th

Filesystem Type Size Used Avail Use% Mounted on

/dev/mapper/centos-root xfs 231G 11G 221G 5% /

devtmpfs devtmpfs 32G 0 32G 0% /dev

tmpfs tmpfs 32G 24K 32G 1% /dev/shm

tmpfs tmpfs 32G 588M 31G 2% /run

tmpfs tmpfs 32G 0 32G 0% /sys/fs/cgroup

/dev/sda1 xfs 494M 130M 364M 27% /boot

/dev/mapper/centos-var xfs 100G 6.7G 94G 7% /var

/dev/mapper/centos-opt xfs 600G 733M 599G 1% /opt

tmpfs tmpfs 6.3G 0 6.3G 0% /run/user/0

/dev/sdc xfs 932G 66G 866G 8% /opt/hdata

/dev/sdb1 xfs 932G 63G 869G 7% /opt/hdata2

/dev/sdd1 xfs 932G 65G 867G 7% /opt/hdata3

/dev/sde1 xfs 932G 67G 866G 8% /opt/hdata4

#Hdfs的datanode目錄磁碟是sdb、sdc、sdd和sde，也就是說hbase儲存在這四塊磁碟上。總的大小大概是4T不到一點，4臺裝置的叢集總大小大約在14.5T左右。

[[email protected]~]# cat /proc/cpuinfo #24核

……………………

processor : 23

vendor_id : GenuineIntel

cpu family : 6

model : 62

model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz

stepping : 4

microcode : 0x428

cpu MHz : 1211.109

cache size : 15360 KB

physical id : 1

siblings : 12

core id : 5

cpu cores : 6

apicid : 43

initial apicid : 43

fpu : yes

fpu_exception : yes

cpuid level : 13

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt

bogomips : 4204.89

clflush size : 64

cache_alignment : 64

address sizes : 46 bits physical, 48 bits virtual

power management:

[[email protected] ~]# ethtool bond0 #網絡卡資訊

Settings for bond0:

Supported ports: [ ]

Supported link modes: Not reported

Supported pause frame use: No

Supports auto-negotiation: No

Advertised link modes: Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: 2000Mb/s

Duplex: Full

Port: Other

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Link detected: yes

[[email protected] ~]# hadoop version #hadoop版本

Hadoop 2.7.1.2.4.2.0-258

Subversion [email protected]:hortonworks/hadoop.git -r 13debf893a605e8a88df18a7d8d214f571e05289

Compiled by jenkins on 2016-04-25T05:46Z

Compiled with protoc 2.5.0

From source with checksum 2a2d95f05ec6c3ac547ed58cab713ac

This command was run using /usr/hdp/2.4.2.0-258/hadoop/hadoop-common-2.7.1.2.4.2.0-258.jar

[[email protected] ~]# hbase version #hbase版本

2016-09-06 14:52:19,070 INFO [main] util.VersionInfo: HBase 1.1.2.2.4.2.0-258

2016-09-06 14:52:19,071 INFO [main] util.VersionInfo: Source code repository file:///grid/0/jenkins/workspace/HDP-build-centos6/bigtop/build/hbase/rpm/BUILD/hbase-1.1.2.2.4.2.0 revision=Unknown

2016-09-06 14:52:19,071 INFO [main] util.VersionInfo: Compiled by jenkins on Mon Apr 25 06:36:21 UTC 2016

2016-09-06 14:52:19,071 INFO [main] util.VersionInfo: From source with checksum 4f661ee4f9f148ce7bfcad5b0d667c27

[[email protected] ~]# hdfs version #hdfs版本

Hadoop 2.7.1.2.4.2.0-258

Subversion [email protected]:hortonworks/hadoop.git -r 13debf893a605e8a88df18a7d8d214f571e05289

Compiled by jenkins on 2016-04-25T05:46Z

Compiled with protoc 2.5.0

From source with checksum 2a2d95f05ec6c3ac547ed58cab713ac

This command was run using /usr/hdp/2.4.2.0-258/hadoop/hadoop-common-2.7.1.2.4.2.0-258.jar

Hadoop叢集共有相同配置的4個node節點，在其他相同配置的叢集以外的node節點上執行ycsb測試程序，hadoop叢集是通過ambari軟體執行維護的，對應的很多配置都是在ambari的web介面上去完成的。

2.2 hadoop配置

這裡的hadoop配置主要包括了hbase和hdfs兩類配置，讀寫在具體配置時會有稍許不同，這個在具體的地方會具體指明。

在後面第4、5章中介紹讀寫配置時沒有單獨指出介紹的配置項一般在兩種情況下都較為適用，而且幾乎都已經調到了最大值，在這裡會統一介紹。

2.2.1 hbase配置

[[email protected] test]# cat /usr/hdp/current/hbase-client/conf/hbase-site.xml

#Todo

<name>dfs.domain.socket.path</name>

<value>/var/lib/hadoop-hdfs/dn_socket</value>

</property>

#Todo

<name>hbase.bulkload.staging.dir</name>

<value>/apps/hbase/staging</value>

</property>

#每條記錄的最大大小為1MB

<name>hbase.client.keyvalue.maxsize</name>

</property>

#hbase client操作失敗重新請求數為35

<name>hbase.client.retries.number</name>

</property>

#當一次scan操作不在本地記憶體時，需要從disk中獲取時，快取的條數，這裡設定為100000條，該值不能大於下文中hbase.client.scanner.timeout.period配置項的值

<name>hbase.client.scanner.caching</name>

</property>

下圖中的第一個配置項hbase.client.scanner.timeout.period對應的是上文中的Number of Fetched Rows when Scanning from Disk，它的值必須小於下圖中的第一個配置項才行。

第二個配置項的話預設是true的，無需額外配置，之前在解決一個相關問題時，將它置為了false。

<name>hbase.client.scanner.timeout.period</name>

</property>

#hbase是否配置為分散式

<name>hbase.cluster.distributed</name>

</property>

#Todo

<name>hbase.coprocessor.master.classes</name>

</property>

#Todo

<name>hbase.coprocessor.region.classes</name>

<value>org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint</value>

</property>

#設定為ture，忽略對預設hbase版本的檢查（設定為false的話在maven工程的編譯過程中可能會遇到版本相關的問題）

<name>hbase.defaults.for.version.skip</name>

</property>

#設定系統進行1次majorcompaction的啟動週期，如果設定為0，則系統不會主動出發MC過程，預設為7天

<name>hbase.hregion.majorcompaction</name>

</property>

#用來作為計算MC時間週期，與hbase.hregion.majorcompaction相結合，計算出一個浮動的MC時間。預設是0.50，簡單來說如果當前store中hfile的最早更新時間早於某個MCTime，就會觸發major compaction，hbase通過這種機制定期刪除過期資料。MCTime是一個浮動值，浮動區間為[ hbase.hregion.majorcompaction - hbase.hregion.majorcompaction * hbase.hregion.majorcompaction.jitter , hbase.hregion.majorcompaction + hbase.hregion.majorcompaction * hbase.hregion.majorcompaction.jitter ]

<name>hbase.hregion.majorcompaction.jitter</name>

</property>

#單個region的大小為10G，當region大於這個值的時候，一個region就會split為兩個，適當的增加這個值的大小可以在寫操作時減少split操作的發生，從而減少系統性能消耗而增加寫操作的效能，預設是10G，官方建議10G~30G

<name>hbase.hregion.max.filesize</name>

</property>

#當一個region的memstore總量達到hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size (預設2*128M)時，會阻塞這個region的寫操作，並強制刷寫到HFile，觸發這個重新整理操作只會在Memstore即將寫滿hbase.hregion.memstore.flush.size時put了一個巨大的記錄的情況，這時候會阻塞寫操作，強制重新整理成功才能繼續寫入

<name>hbase.hregion.memstore.block.multiplier</name>

</property>

#每個單獨的memstore的大小（預設128M），這裡調成了256M，每個列族columnfamily在每個region中都分配有它單獨的memstore，當memstore超過該值時，就會發生flush操作，將memstore中的內容刷成一個hfile，每一次memstore的flush操作，都會為每一次columnfamily建立一個新的hfile；調高該值可以減少flush的操作次數，減少每一個region中的hfile的個數，這樣就會減少minor compaction的次數和split的次數，從而降低了系統性能損耗，提升了寫效能，也提升了讀效能（因為讀操作的時候，首先要去memstore中查資料，查詢不到的話再去hfile，hflie儲存在hdfs中，這就涉及到了對效能要求較高的io操作了）。當然這個值變大了之後，每次flush操作帶來的效能消耗也就更大。

<name>hbase.hregion.memstore.flush.size</name>

</property>

#mslab特性是在分析了HBase產生記憶體碎片後的根因後給出瞭解決方案，這個方案雖然不能夠完全解決Full GC帶來的問題，但在一定程度上延緩了Full GC的產生間隔，總之減少了記憶體碎片導致的full gc，提高整體效能。

<name>hbase.hregion.memstore.mslab.enabled</name>

</property>

#當任意一個store中有超過hbase.hstore.blockingStoreFiles個數的storefiles時，這個store所在region的update操作將會被阻塞，除非這個region的compaction操作完成或者hbase.hstore.blockingWaitTime超時。

Block操作會嚴重影響當前regionserver的響應時間，但過多的storefiles會影響讀效能，站在實際使用的角度，為了獲取較為平滑的響應時間，可以將該值設得很大，甚至無限大。預設值為7，這裡暫時調大到100。

<name>hbase.hstore.blockingStoreFiles</name>

</property>

#一次minor compaction的最大file數

<name>hbase.hstore.compaction.max</name>

</property>

#一次minor compaction的最小file數

<name>hbase.hstore.compactionThreshold</name>

</property>

#本地檔案目錄用來作為hbase在本地的儲存

<name>hbase.local.dir</name>

<value>${hbase.tmp.dir}/local</value>

</property>

#todo

#與前文配置項圖中第二紅線標註的配置項重複

<name>hbase.master.distributed.log.splitting</name>

</property>

#hbase master web介面繫結的IP地址（任何網絡卡的ip都可以訪問）

<name>hbase.master.info.bindAddress</name>

</property>

#hbase master web介面繫結埠

<name>hbase.master.info.port</name>

</property>

#todo

<name>hbase.master.port</name>

</property>

#分配1%的regionserver的記憶體給寫操作當作快取，這個引數和下面的hfile.block.cache.size（讀快取）息息相關，二者之和不能超過總記憶體的80%，讀操作時，該值最好為0，但是這裡有個bug，取不到0，所以取值1%即0.01，系統儘可能的把記憶體給讀操作用作快取

<name>hbase.regionserver.global.memstore.size</name>

</property>

#regionserver處理IO請求的執行緒數，預設是30這裡調高到240

<name>hbase.regionserver.handler.count</name>

</property>

#regionserver 資訊 web介面介面

<name>hbase.regionserver.info.port</name>

</property>

#regionserver服務埠

<name>hbase.regionserver.port</name>

</property>

#todo

<name>hbase.regionserver.wal.codec</name>

<value>org.apache.hadoop.hbase.regionserver.wal.WALCellCodec</value>

</property>

#hbase所有表的檔案存放在hdfs中的路徑，使用者可以在hdfs的web頁面和後臺命令列中檢視，若要徹底刪除表，現在hbase中刪除，然後在hdfs中刪除原始檔即可，drop命令執行過後hdfs上內容沒有刪除情況下。

<name>hbase.rootdir</name>

<value>hdfs://node1.dcom:8020/apps/hbase/data</value>

</property>

#todo

<name>hbase.rpc.protection</name>

<value>authentication</value>

</property>

#hbase rpc操作超時時間

<name>hbase.rpc.timeout</name>

</property>

#todo

<name>hbase.security.authentication</name>

<value>simple</value>

</property>

#todo

<name>hbase.security.authorization</name>

<value>false</value>

</property>

#todo

<name>hbase.superuser</name>

<value>hbase</value>

</property>

#本地檔案系統上的臨時目錄，最好不要使用/tmp下的目錄，以免重啟後丟失檔案

<name>hbase.tmp.dir</name>

<value>/tmp/hbase-${user.name}</value>

</property>

#zookeeper配置檔案zoo.cfg中定義的內容，zookeeper 客戶端通過該port連線上zookeeper服務

<name>hbase.zookeeper.property.clientPort</name>

</property>

#zookeeper服務的節點數目和各節點名稱

<name>hbase.zookeeper.quorum</name>

</property>

#zookeeper支援多重update

<name>hbase.zookeeper.useMulti</name>

</property>

#將regionserver的記憶體的79%分配作為讀快取，預設是40%，這裡因為是單獨的讀操作效能調優所以調到了79%，上文中提到了一個bug，不能調為最高的80%。該配置項與上文中的hbase.regionserver.global.memstore.size關係密切，二者的總和不能大於regionserver記憶體的80%，讀操作為主時就將該值調高，寫操作為主時就將hbase.regionserver.global.memstore.size調高

<name>hfile.block.cache.size</name>

</property>

#todo

<name>phoenix.query.timeoutMs</name>

</property>

#zookeeper session會話超時時間

<name>zookeeper.session.timeout</name>

</property>

#znode 存放root region的地址

#todo

<name>zookeeper.znode.parent</name>

<value>/hbase-unsecure</value>

</property>

</configuration>

# RegionServers maximum value for –Xmn 新生代jvm記憶體大小，預設是1024，這裡調到了4096，這個引數影響到regionserver 的jvm的CMS GC，64G記憶體的話建議1~3G，最大為4G，regionserver –Xmn in –Xmx ratio配置項也密切相關，該比例設定的太大或者太小都不好，這方面涉及到的內容太多，後續再詳細介紹。

# Number of Fetched Rows when Scanning from Disk這個就是上文中提到的hbase.client.scanner.caching

# Maximum Store Files before Minor Compaction 在執行Minor Compaction合併操作前Store Files的最大數目，預設是3，這裡調到了4

# The maximum amount of heap to use, in MB. Default is 1000.

#export HBASE_HEAPSIZE=3000 分配給hbase服務的記憶體，預設是1000，由於hbase較耗記憶體，所以提高到了3000

這個地方有疑問：這裡配置這麼小的記憶體到底是給誰用的？

2.2.2 hdfs配置

相關配置介紹：

(1) NameNode directories

這裡配置了4個namenode目錄，分別掛載在不同的硬碟上。Namenode的目錄，只在namenode節點上有內容，datanode節點上該目錄為空，且namenode節點上該目錄的內容都是一樣的（其他的作為備份）。

(2) DataNode directories

這裡配置了4個datanode目錄，分別掛載在不同的硬碟上。Datanode目錄在每個datanode節點上都有實際的內容，儲存著真正的hdfs資料和備份。

(3) Namenode_heapsize

Namenode節點的java執行記憶體，預設1G，這裡調高到了3G。

(4) dtnode_heapsize

預設為1G，這裡調大到了12G，也不能太大，否則datanode啟動時會因為無法分配足夠記憶體而報錯。

(5) Dfs.datanode.max.transfer.threads

Datanode傳輸資料執行緒數，預設16384調大到了48000。

2.2.3 其他配置

（1）另外還有幾個重要的配置引數介紹一下（這裡其實是我遇到個一個疑問）

Hbase.regionserver.global.memstore.uppperLimit預設0.4

Hbase.regionserver.global.memstore.lowerLimit預設0.35

一個regionserver會有多個region，多個memstore，所以可能單個region並沒有超過閾值，但是整個regionserver的記憶體佔用已經非常多了，上面這兩個引數也會去控制和影響記憶體的刷寫，當regionserver上全部的memstore佔用超過heap（heap的值在hbase-env.sh中設定，HBASE_HEAPSIZE預設為1000，我們這裡設定為3000）的40%時，強制阻塞所有的寫操作，將所有的memstore刷寫到HFile；當所有的memstore佔用超過heap的35%時，會選擇一些佔用記憶體比較大的memstore阻塞寫操作並進行flush。

注意：

這兩個配置項，在當前的環境中並未找到！懷疑是直接當作預設值，使用者可以自行新增修改？

3 測試步驟

這裡簡單介紹下具體測試時的大體步驟，關於ycsb工具使用的細節需要結合ycsb使用文件閱讀理解。

3.1.1 預分割槽和建表

Hbase shell 操作：

hbase(main):033:0>n_splits=200

=> 200 #200個region分割槽

hbase(main):032:0> create

'a',{NAME=>'cf'},{SPLITS=>(1...n_splits).map{|i|"user#{1000000+i*(9999999-1000000)/n_splits}"}}

0 row(s) in28.4070 seconds

=>Hbase::Table – a #建立名為a，列族1個名為cf，分割槽region200個，並通過一定的演算法使得rowkey的分佈呈一定的規律

採用預分割槽和rowkey均勻分佈的方式建立表格能夠很大程度上提高hbase的讀寫效能。

3.1.2 裝載初始化資料庫

插入資料 ycsb的load階段（測試寫入效能）。

[[email protected]]# sh ycsb_load.sh load

******Loadingtest begin******

******Loadingtest end******

Load檔案即為執行load階段時ycsb的配置檔案

3.1.3 對資料庫進行操作

ycsb的run階段（配置引數例如read、scan操作可測試讀取效能）。

[[email protected]]# sh ycsb_run.sh run

******runningtest begin******

******runningtest end******

run檔案即為執行run階段時ycsb的配置檔案

4 讀效能測試與調優

4.1 Scan操作

Hbase叢集四臺節點的top、iostat和頻寬記錄值以及ycsb配置檔案見本文件附帶的檔案目錄。

YCSB scan操作掃描hbase資料庫，測試結果：

操作	分割槽數	value長度	速度條/秒	叢集節點數	ycsb client節點數	頻寬	運算元	瓶頸
掃描scan	200 regions	9216bytes	85000~90000左右	4	4	1500~1600Mb/s	200000	頻寬、ycsb clinet 記憶體
掃描scan	200 regions	9216bytes	20000左右	4	1	1850Mb/s	200000	頻寬

Scan操作選取了兩個結果，第一個運行了4個ycsb client，第二個只有1個ycsb client第二個的瓶頸明顯是頻寬。

由於ycsb 和hbase 的scan操作特點所以這裡具體的操作速度都是通過頻寬估算出來的。

4.1.1 配置調優重點

Hbase的scan操作是一種批量讀取的操作，scan與read不同，scan一次性請求大量資料，預設的話是讀取全表，這就需要在客戶端的本地佔用很大的記憶體來快取一次批量拉取的資料，下面介紹一下幾個關係密切的配置項。

讀取hbase資料的順序是：

先去memstore中查詢，找不到再去blockcahe中，如果沒有就去hdfs中查詢，找到之後讀取的同時儲存一份到blockcahe中便於下次查詢。

memstore和blockcahe都是在記憶體中查詢速度很快，延時很低，效能很好，而在hdfs中查詢和讀取就涉及到磁碟的讀取操作，磁碟IO消耗效能較大。

（1）hadoop配置

#當一次scan操作不在本地記憶體時，需要從disk中獲取時，快取的條數，這裡設定為100000條，該值不能大於下文中hbase.client.scanner.timeout.period配置項的值。該數值也並不是越高越好，太高的話scan超時時間就會很長，影響效能，一次性獲取條數固然多，但由於頻寬和其他的限制並不能很好的消化掉，太低當然也不行，配置時需要根據具體情況具體設定。

一條資料長度為9k的話，一次快取100000條就需要900MB，所以對ycsb client端有較高的記憶體要求。

<name>hbase.client.scanner.caching</name>

</property>

#Scanner超時時間，必須大於hbase.client.scanner.caching的數值。這個引數是在配置hbase.client.scanner.caching後hadoop報錯之後我自己加的。

<name>hbase.client.scanner.timeout.period</name>

</property>

（2）ycsb配置

這裡有必要解釋一下ycsb在scan時的原理：

Ycsb利用自己的hash演算法生成一個rowkey，然後每次在1~ maxscanlength裡選取一個值作為本次要掃描的條數。

ycsb配置檔案關鍵項：

##節選 ycsb配置檔案

maxscanlength=20000 #每次最多能掃描的條數

#scanlengthdistribution=zipfian #獲取scanlength的概率分佈，預設是uniform等概率隨機分佈

requestdistribution=latest #讀取最近更新過的資料，存在熱點資料，但根據LRU blockcache原理這種選擇效能更好

##節選 ycsb配置檔案

4.1.2 Ycsb client狀態

一共有4個ycsb client節點，四個系統狀態基本一致，可能在某些引數上有少許差別，ycsbclient上沒有對磁碟進行操作，所以沒有記錄iostat命令。

（1）Top命令：

[[email protected] test]# top

top - 02:44:17 up 49 days, 16:20, 8 users, load average: 2.28, 1.51, 1.24

Tasks: 372 total, 1 running, 371 sleeping, 0 stopped, 0 zombie

%Cpu(s): 4.6 us, 0.1 sy, 0.0 ni, 95.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65772144 total, 7317380 free, 54500600 used, 3954164 buff/cache

KiB Swap: 0 total, 0 free, 0 used. 10777744 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

20073 root 20 0 64.803g 0.049t 14944 S 62.5 80.4 483:46.18 java

11669 root 20 0 148356 2152 1384 R 6.2 0.0 0:00.01 top

17433 root 20 0 978192 35864 5000 S 6.2 0.1 21:02.36 python

1 root 20 0 49520 11668 2064 S 0.0 0.0 9:13.75 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:00.34 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:02.20 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H

7 root rt 0 0 0 0 S 0.0 0.0 0:01.77 migration/0

可知，scan讀狀態下主要消耗的是系統的記憶體，達到了80%以上將近52G，但cpu佔用很低。

（2）頻寬

[Tue Sep 13 02:44:08 CST 2016] IN: 1389094904Bps(1324Mbps) OUT: 7091152Bps(6Mbps)

[Tue Sep 13 02:44:09 CST 2016] IN: 1404023672Bps(1338Mbps) OUT: 7577184Bps(7Mbps)

[Tue Sep 13 02:44:10 CST 2016] IN: 1508430248Bps(1438Mbps) OUT: 7674216Bps(7Mbps)

[Tue Sep 13 02:44:11 CST 2016] IN: 1437603968Bps(1371Mbps) OUT: 7205992Bps(6Mbps)

[Tue Sep 13 02:44:12 CST 2016] IN: 720413848Bps(687Mbps) OUT: 3720896Bps(3Mbps)

[Tue Sep 13 02:44:13 CST 2016] IN: 1259848896Bps(1201Mbps) OUT: 6752184Bps(6Mbps)

[Tue Sep 13 02:44:14 CST 2016] IN: 1291553552Bps(1231Mbps) OUT: 7213832Bps(6Mbps)

[Tue Sep 13 02:44:15 CST 2016] IN: 1250500584Bps(1192Mbps) OUT: 6809800Bps(6Mbps)

[Tue Sep 13 02:44:16 CST 2016] IN: 1245858144Bps(1188Mbps) OUT: 6811296Bps(6Mbps)

[Tue Sep 13 02:44:17 CST 2016] IN: 1290120160Bps(1230Mbps) OUT: 6957832Bps(6Mbps)

[Tue Sep 13 02:44:18 CST 2016] IN: 1309091656Bps(1248Mbps) OUT: 6893712Bps(6Mbps)

[Tue Sep 13 02:44:19 CST 2016] IN: 1231891208Bps(1174Mbps) OUT: 6519600Bps(6Mbps)

[Tue Sep 13 02:44:20 CST 2016] IN: 1200068072Bps(1144Mbps) OUT: 6494376Bps(6Mbps)

[Tue Sep 13 02:44:21 CST 2016] IN: 1232850840Bps(1175Mbps) OUT: 6436968Bps(6Mbps)

[Tue Sep 13 02:44:22 CST 2016] IN: 1248240840Bps(1190Mbps) OUT: 6216216Bps(5Mbps)

[Tue Sep 13 02:44:23 CST 2016] IN: 1071171808Bps(1021Mbps) OUT: 5650304Bps(5Mbps)

[Tue Sep 13 02:44:24 CST 2016] IN: 1268564440Bps(1209Mbps) OUT: 6902568Bps(6Mbps)

[Tue Sep 13 02:44:25 CST 2016] IN: 1264221552Bps(1205Mbps) OUT: 6871656Bps(6Mbps)

[Tue Sep 13 02:44:26 CST 2016] IN: 1256361264Bps(1198Mbps) OUT: 6637352Bps(6Mbps)

此刻這臺裝置的IN頻寬大概在1200~1300Mbps左右。

（3）ycsb配置

# The thread count

threadcount=300 #300個執行緒

# The number of fields in a record

fieldcount=1

# The size of each field (in bytes)

fieldlength=9216 #一條記錄長度為9KB

# Number of Records will be loaded

recordcount=20000000

# Number of Operations will be handle in run parsh

operationcount=2000000 #scan操作2百萬次

readallfields=true

insertorder=hashed

#insertstart=0

#insertcount=500000000

# Control Porption of hbase operation type

readproportion=0

updateproportion=0

scanproportion=1 #完全scan操作

insertproportion=0

# The following param always be fixed

# The table name

table=usertable

# The colume family

columnfamily=cf

# The workload class

workload=com.yahoo.ycsb.workloads.CoreWorkload

# The measurement type

measurementtype=raw

clientbuffering=true

writebuffersize=12582912

#requestdistribution=zipfian

maxscanlength=20000

#hbase.usepagefilter=false

#scanlengthdistribution=zipfian

requestdistribution=latest #請求最近讀取過的資料，與LRU讀快取結合較好

4.1.3 Hbase節點狀態

4臺裝置組成的hbase叢集，這裡選取其中1臺的系統狀態，其餘3臺的狀態基本與選取的狀態一致。

（1）Iostat

09/13/2016 02:44:54 AM

avg-cpu: %user %nice %system %iowait %steal %idle

7.81 0.00 0.66 0.85 0.00 90.69

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util

sdd 0.06 0.00 25.52 0.01 3.17 0.00 254.14 0.13 5.23 5.23 8.33 2.58 6.58

sda 0.00 0.29 0.02 2.25 0.00 0.02 16.64 0.01 3.13 11.54 3.05 1.85 0.42

sdc 0.11 0.00 29.00 0.00 3.76 0.00 265.38 0.19 6.69 6.69 0.00 2.97 8.61

sdb 0.12 0.00 30.55 0.11 4.14 0.00 276.66 0.21 6.80 6.80 7.08 2.91 8.92

sde 0.08 0.00 24.61 0.00 2.97 0.00 247.51 0.13 5.14 5.14 0.00 2.66 6.55

dm-0 0.00 0.00 0.02 1.26 0.00 0.01 12.47 0.00 2.81 11.54 2.66 1.24 0.16

dm-1 0.00 0.00 0.00 0.11 0.00 0.00 10.46 0.00 3.89 0.00 3.89 3.14 0.03

dm-2 0.00 0.00 0.00 1.06 0.00 0.01 19.57 0.00 3.40 0.00 3.40 2.20 0.23

可知，在讀狀態下，由於設定了較大的讀快取blockcache和scan本身的特性，所以對磁碟的io操作並不多。

（2）Top

[[email protected] ~]# top

top - 02:42:14 up 6 days, 11:15, 5 users, load average: 1.35, 1.66, 1.81

Tasks: 401 total, 1 running, 394 sleeping, 6 stopped, 0 zombie

%Cpu(s): 2.9 us, 0.4 sy, 0.0 ni, 96.3 id, 0.4 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65773904 total, 358628 free, 54028200 used, 11387076 buff/cache

KiB Swap: 0 total, 0 free, 0 used. 11329324 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

28879 hbase 20 0 52.267g 0.046t 29116 S 143.8 74.9 1346:45 java

18644 root 20 0 146272 2164 1352 R 6.2 0.0 0:00.01 top

1 root 20 0 45288 7428 1988 S 0.0 0.0 2:15.42 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:00.18 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:00.95 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H

7 root rt 0 0 0 0 S 0.0 0.0 0:02.31 migration/0

8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh

主要是記憶體的消耗，cpu佔用不多，記憶體大小由使用者維護的hbase-site.xml中的hbase_regionserver_heapsize決定，這裡已接近用掉了50G的記憶體，很大一部分用作了讀快取。

（3）頻寬

[Tue Sep 13 02:44:11 CST 2016] IN: 22436840Bps(21Mbps) OUT: 1471864896Bps(1403Mbps)

[Tue Sep 13 02:44:12 CST 2016] IN: 13982576Bps(13Mbps) OUT: 1353348496Bps(1290Mbps)

[Tue Sep 13 02:44:13 CST 2016] IN: 41001296Bps(39Mbps) OUT: 1415041312Bps(1349Mbps)

[Tue Sep 13 02:44:14 CST 2016] IN: 24540680Bps(23Mbps) OUT: 1251462792Bps(1193Mbps)

[Tue Sep 13 02:44:15 CST 2016] IN: 23827832Bps(22Mbps) OUT: 1320654496Bps(1259Mbps)

[Tue Sep 13 02:44:16 CST 2016] IN: 19069888Bps(18Mbps) OUT: 1281471968Bps(1222Mbps)

[Tue Sep 13 02:44:17 CST 2016] IN: 40502944Bps(38Mbps) OUT: 1290429472Bps(1230Mbps)

[Tue Sep 13 02:44:18 CST 2016] IN: 15378312Bps(14Mbps) OUT: 1298991384Bps(1238Mbps)

[Tue Sep 13 02:44:19 CST 2016] IN: 23261504Bps(22Mbps) OUT: 1231679168Bps(1174Mbps)

[Tue Sep 13 02:44:20 CST 2016] IN: 20102808Bps(19Mbps) OUT: 1205856648Bps(1149Mbps)

[Tue Sep 13 02:44:21 CST 2016] IN: 27994376Bps(26Mbps) OUT: 1162188960Bps(1108Mbps)

[Tue Sep 13 02:44:22 CST 2016] IN: 20662608Bps(19Mbps) OUT: 995859928Bps(949Mbps)

[Tue Sep 13 02:44:23 CST 2016] IN: 31011776Bps(29Mbps) OUT: 1285450232Bps(1225Mbps)

[Tue Sep 13 02:44:24 CST 2016] IN: 14276128Bps(13Mbps) OUT: 1127933176Bps(1075Mbps)

[Tue Sep 13 02:44:25 CST 2016] IN: 50224704Bps(47Mbps) OUT: 1179008864Bps(1124Mbps)

[Tue Sep 13 02:44:26 CST 2016] IN: 26989040Bps(25Mbps) OUT: 1386031752Bps(1321Mbps)

[Tue Sep 13 02:44:27 CST 2016] IN: 26029776Bps(24Mbps) OUT: 1383180992Bps(1319Mbps)

[Tue Sep 13 02:44:28 CST 2016] IN: 73159800Bps(69Mbps) OUT: 1392148184Bps(1327Mbps)

[Tue Sep 13 02:44:29 CST 2016] IN: 27760800Bps(26Mbps) OUT: 1339476496Bps(1277Mbps)

[Tue Sep 13 02:44:30 CST 2016] IN: 19761192Bps(18Mbps) OUT: 1207076944Bps(1151Mbps)

[Tue Sep 13 02:44:31 CST 2016] IN: 19563336Bps(18Mbps) OUT: 1242348416Bps(1184Mbps)

與ycsb client節點類似，此刻的OUT頻寬在1200~1300Mbps左右。

4.2 Read操作

Read操作和scan操作有一些類似，都是客戶端向hbase server端請求資料，不同的是read一次只請求一條，而scan一次可以請求多條即批量讀取，因此scan操作對hbase client的記憶體有較高的要求。

在當前裝置環境中，單臺伺服器上Ycsb client執行讀read操作時，最多大約可以開啟30000個threads。採用越多的ycsb threads的話，在真正對資料進行操作前的準備時間也就越長，會影響最終獲得的每秒運算元。30000的threads大概read 20000t/s，頻寬已達到極限1850Mb/s，測試結果如下：

分割槽數	value長度	速度條/秒	叢集節點數	ycsb client節點數	頻寬	運算元	瓶頸
讀取read	200 regions	9216bytes	45000~50000左右	4	4	1100~1200Mb/s	20000000	hbase clinet 記憶體
讀取read	200 regions	9216bytes	20000左右	4	1	1850Mb/s	20000000	頻寬

這裡也選取了兩個結果，第一個運行了4個ycsb client，第二個執行1個ycsb client很明顯單個ycsb client進行read讀取操作時的瓶頸在於頻寬。

4.2.1 配置調優要點

Hbase本身提供了讀快取，具體可以檢視上面hbase-site.xml檔案解析，本叢集環境中每個regionserver可提供最多40G左右的讀快取。

簡單介紹下Hbase讀操作read的原理，首先去memstore中查詢，查不到就在讀快取blockcache中查詢，再查不到就去hdfs也就是硬碟中查，並且將查到的結果放置在讀快取blockcache中以便下次查詢。Blockcache是一個LRU，當blockcache達到上限（heapsize*hfile.block.cache.size*0.85）時，會啟動淘汰機制，淘汰掉最老的一批資料。

Scan操作可以設定每次scan取到的條數，一次讀的越大每條資料消耗的RPC也就越少，效能也就相應會提高，但是設定的越大對記憶體的要求也就越高，應根據實際裝置效能調整大小。

（1）hadoop配置

這裡介紹幾個關鍵配置：

#分配1%的regionserver的記憶體給寫操作當作快取，這個引數和下面的hfile.block.cache.size（讀快取）息息相關，二者之和不能超過總記憶體的80%，讀操作時，該值最好為0，但是這裡有個bug，取不到0，所以取值1%即0.01，系統儘可能的把記憶體給讀操作用作快取。

<name>hbase.regionserver.global.memstore.size</name>

</property>

<name>hfile.block.cache.size</name>

</property>

（2）ycsb配置

Ycsb 配置檔案關鍵項：

##ycsb 配置檔案節選

requestdistribution=latest #資料請求模式，最近訪問的資料，非等概率與LRU快取結合較好

##ycsb 配置檔案節選

4.2.2 ycsb client狀態

一共有4個ycsb client節點，四個系統狀態基本一致，可能在某些引數上有少許差別，ycsbclient上沒有對磁碟進行操作，所以沒有記錄iostat命令

這裡的話ycsb client的thread數幾乎已經到了極限（20000、30000）。下面分析的是跑了4個ycsb client的情況，單獨1個ycsb client暫不分析。

（1）top

top - 16:28:13 up 71 days, 7:20, 6 users, load average: 3.52, 3.50, 3.17

Tasks: 395 total, 1 running, 394 sleeping, 0 stopped, 0 zombie

%Cpu(s): 2.0 us, 0.4 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65772144 total, 28988184 free, 30913756 used, 5870204 buff/cache

KiB Swap: 33030140 total, 32722816 free, 307324 used. 34177996 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

4721 root 20 0 82.531g 0.021t 14956 S 288.9 33.8 95:40.78 java

1985 root 20 0 148356 2148 1384 R 11.1 0.0 0:00.03 top

8520 hbase 20 0 505952 8864 2624 S 5.6 0.0 707:06.23 python2.7

24980 yarn 20 0 2069392 337560 24480 S 5.6 0.5 20:29.57 java

1 root 20 0 203556 18160 2144 S 0.0 0.0 17:05.19 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:01.37 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:07.33 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H

由上可知，read操作對於cpu和記憶體的壓力都不是很大。

（2）頻寬

[Tue Sep 13 16:28:04 CST 2016] IN: 1090692056Bps(1040Mbps) OUT: 28791808Bps(27Mbps)

[Tue Sep 13 16:28:05 CST 2016] IN: 1050596840Bps(1001Mbps) OUT: 27955120Bps(26Mbps)

[Tue Sep 13 16:28:06 CST 2016] IN: 1455753528Bps(1388Mbps) OUT: 37571904Bps(35Mbps)

[Tue Sep 13 16:28:07 CST 2016] IN: 1431038136Bps(1364Mbps) OUT: 36814408Bps(35Mbps)

[Tue Sep 13 16:28:08 CST 2016] IN: 87732120Bps(83Mbps) OUT: 52472Bps(0Mbps)

[Tue Sep 13 16:28:09 CST 2016] IN: 58797728Bps(56Mbps) OUT: 1438416Bps(1Mbps)

[Tue Sep 13 16:28:10 CST 2016] IN: 1630987592Bps(1555Mbps) OUT: 42776208Bps(40Mbps)

[Tue Sep 13 16:28:11 CST 2016] IN: 771773360Bps(736Mbps) OUT: 19205928Bps(18Mbps)

[Tue Sep 13 16:28:12 CST 2016] IN: 1240965184Bps(1183Mbps) OUT: 32610560Bps(31Mbps)

[Tue Sep 13 16:28:13 CST 2016] IN: 1310319648Bps(1249Mbps) OUT: 33690016Bps(32Mbps)

[Tue Sep 13 16:28:14 CST 2016] IN: 1481654992Bps(1413Mbps) OUT: 38381168Bps(36Mbps)

[Tue Sep 13 16:28:15 CST 2016] IN: 1342465440Bps(1280Mbps) OUT: 35507448Bps(33Mbps)

[Tue Sep 13 16:28:16 CST 2016] IN: 991861888Bps(945Mbps) OUT: 25188448Bps(24Mbps)

[Tue Sep 13 16:28:17 CST 2016] IN: 1455500744Bps(1388Mbps) OUT: 38124632Bps(36Mbps)

[Tue Sep 13 16:28:18 CST 2016] IN: 1562847648Bps(1490Mbps) OUT: 40131136Bps(38Mbps)

[Tue Sep 13 16:28:19 CST 2016] IN: 1353514144Bps(1290Mbps) OUT: 34863296Bps(33Mbps)

[Tue Sep 13 16:28:20 CST 2016] IN: 990938744Bps(945Mbps) OUT: 25207296Bps(24Mbps)

[Tue Sep 13 16:28:21 CST 2016] IN: 1352270600Bps(1289Mbps) OUT: 36755976Bps(35Mbps)

[Tue Sep 13 16:28:22 CST 2016] IN: 1342217736Bps(1280Mbps) OUT: 35219184Bps(33Mbps)

總體頻寬平均在1100Mbps左右。

（3）ycsb 配置

# The thread count

threadcount=20000 #起2萬個執行緒，當前環境最多起30000個左右

# The number of fields in a record

fieldcount=1

# The size of each field (in bytes)

fieldlength=9216 #一條資料長度為9KB

# Number of Records will be loaded

recordcount=20000000

# Number of Operations will be handle in run parsh

operationcount=20000000 #讀取2千萬條資料

readallfields=true

insertorder=hashed

#insertstart=0

#insertcount=500000000

# Control Porption of hbase operation type

readproportion=1

updateproportion=0

scanproportion=0

insertproportion=0

# The following param always be fixed

# The table name

table=usertable

# The colume family

columnfamily=cf

# The workload class

workload=com.yahoo.ycsb.workloads.CoreWorkload

# The measurement type

measurementtype=raw

clientbuffering=true

writebuffersize=12582912

#requestdistribution=zipfian

maxscanlength=20000

#hbase.usepagefilter=false

#scanlengthdistribution=zipfian

requestdistribution=latest #資料請求模式，最近訪問的資料，非等概率與LRU快取結合較好

4.2.3 hbase節點狀態

4臺裝置組成的hbase叢集，這裡選取其中1臺的系統狀態，其餘3臺的狀態基本與選取的狀態一致。

（1） iostat

09/13/2016 04:28:36 PM

avg-cpu: %user %nice %system %iowait %steal %idle

13.57 0.00 1.45 21.11 0.00 63.86

Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util

sdd 0.12 0.00 70.17 0.05 10.23 0.00 298.41 4.99 71.00 71.04 23.33 9.24 64.90

sda 0.00 0.20 0.05 1.98 0.00 0.02 16.52 0.01 2.49 0.33 2.55 1.82 0.37

sdc 0.05 0.00 75.37 0.05 11.14 0.00 302.59 6.68 88.59 88.54 164.33 9.15 69.03

sdb 0.05 0.00 67.18 0.05 9.83 0.00 299.35 4.13 61.34 61.36 30.00 8.91 59.90

sde 0.02 0.00 62.60 0.13 9.19 0.00 300.02 2.51 40.07 40.11 21.25 7.88 49.42

dm-0 0.00 0.00 0.05 1.10 0.00 0.01 12.06 0.00 1.30 0.33 1.35 0.99 0.11

dm-1 0.00 0.00 0.00 0.05 0.00 0.00 8.00 0.00 6.00 0.00 6.00 6.00 0.03

dm-2 0.00 0.00 0.00 0.93 0.00 0.01 20.71 0.00 3.59 0.00 3.59 2.43 0.23

可知，4塊hdfs磁碟的讀壓力不是很大，這是因為設定了較大的LRU快取。

（2）top

top - 16:28:44 up 7 days, 1:02, 5 users, load average: 26.92, 70.49, 67.85

Tasks: 419 total, 2 running, 411 sleeping, 6 stopped, 0 zombie

%Cpu(s): 3.5 us, 0.4 sy, 0.0 ni, 95.4 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st

KiB Mem : 65773904 total, 432196 free, 53853744 used, 11487964 buff/cache

KiB Swap: 0 total, 0 free, 0 used. 11494572 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

28879 hbase 20 0 52.273g 0.046t 6756 S 1819 74.9 3266:44 java

28970 ambari-+ 20 0 4843484 20372 8148 S 75.0 0.0 0:00.13 java

1184 root 20 0 4372 584 488 S 12.5 0.0 117:57.11 rngd

2941 root 20 0 2273740 43784 2972 S 6.2 0.1 341:08.54 python

29452 root 20 0 146408 2188 1352 R 6.2 0.0 0:00.02 top

1 root 20 0 45700 7776 1964 S 0.0 0.0 2:24.08 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:00.20 kthreadd

3 root 20 0 0 0 0 S 0.0 0.0 0:01.14 ksoftirqd/0

5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H

7 root rt 0 0 0 0 S 0.0 0.0 0:02.69 migration/0

可知，hbase server節點的記憶體佔用較高，這是因為我們手動配置了較多的記憶體，cpu的話佔用並不多。

（3）頻寬

[Tue Sep 13 16:28:35 CST 2016] IN: 22483256Bps(21Mbps) OUT: 661447256Bps(630Mbps)

[Tue Sep 13 16:28:36 CST 2016] IN: 23613704Bps(22Mbps) OUT: 656564224Bps(626Mbps)

[Tue Sep 13 16:28:37 CST 2016] IN: 22772616Bps(21Mbps) OUT: 647350776Bps(617Mbps)

[Tue Sep 13 16:28:38 CST 2016] IN: 18973704Bps(18Mbps) OUT: 605782640Bps(577Mbps)

[Tue Sep 13 16:28:39 CST 2016] IN: 203

hbase讀寫效能測試調優_初稿

1 前言

2 配置

2.1 叢集配置

2.2 hadoop配置

2.2.1 hbase配置

2.2.2 hdfs配置

2.2.3 其他配置

3 測試步驟

3.1.1 預分割槽和建表

3.1.2 裝載初始化資料庫

3.1.3 對資料庫進行操作

4 讀效能測試與調優

4.1 Scan操作

4.1.1 配置調優重點

4.1.2 Ycsb client狀態

4.1.3 Hbase節點狀態

4.2 Read操作

4.2.1 配置調優要點

4.2.2 ycsb client狀態

4.2.3 hbase節點狀態

相關推薦