测试环境:
3台RegionServer,每台的配置如下:
cpu: 32 core
mem: 48 GB,每台RS分配16GB
RS RPC Handler: 300
Test-1 Random Read:
随机读压力 |
|
|
|
|
|
|
OperationType |
|
RandomRead Latency |
|
|
BlockCacheHitRation |
Rpc.Call.Queue |
client随机读线程数量 |
ClusterQps |
Average(ms) |
95线(ms) |
99线(ms) |
|
|
50 |
9003 |
6 |
19 |
37 |
80% |
~ |
100 |
11956 |
9 |
34 |
76 |
80% |
~ |
200 |
18496 |
11 |
53 |
139 |
80% |
~ |
300 |
21206 |
15 |
74 |
176 |
80% |
~ |
400 |
23089 |
18 |
94 |
233 |
80% |
~ |
500 |
24380 |
22 |
106 |
286 |
80% |
40 |
600 |
24805 |
26 |
115 |
302 |
80% |
100 |
300*(2 client) |
25225 |
26 |
110 |
310 |
80% |
120 |
200*(3 client) |
24938 |
26 |
110 |
317 |
80% |
150 |
800 |
18823 |
46 |
182 |
403 |
80% |
300 |
由于测试操作是在对数据blockcache进行了预热操作,所以每次测试的缓存命中率都在80%左右,去除了缓存对读性能的影响。从上述测试数据看出,随着client读线程数量的增加,HBase集群的Qps逐渐升高,同时平均读延迟有所升高,但是在500个线程之前的访问延迟都是可以接受的。在600个线程之后的访问中,Qps逐渐减低,延迟增大,主要原因就是RegionServer的RPC.CallQueue逐渐增大,即RS的RPCHandler(300个)不足与承担此时的Qps压力。
Test-2 Random & Scan Read:
混合压力 |
|
|
|
|
|
OperationType |
|
RandomRead Latency |
Scan |
BlockCacheHitRation |
Rpc.Call.Queue |
client随机读线程数量 |
ClusterQps |
Average(ms) |
Average(ms) |
Average(%) |
Average(个) |
100*(2client) |
140000 |
22 |
800 |
75% |
<5 |
200*(2client) |
151500 |
40 |
1500 |
75% |
60 |
300*(2client) |
192700 |
70 |
1800 |
75% |
330 |
400*(2client) |
204000 |
100 |
2000 |
75% |
340 |
|
|
|
|
|
|
|
|
|
|
|
|
Test-2的压力模式,主要是大概模拟HBase1号集群的访问:
readproportion=0.3 30%的随机读
updateproportion=0.1 10%的更新操作
scanproportion=0.3 30%的scan
insertproportion=0.1 10%的插入
readmodifywriteproportion=0.2 20%的读取修改然后写入操作
丛数据看出,随着访问线程数目的增加,Qps剧烈增加,同时随机读延迟/scan延迟都在增加,因为RPC.CallQueue的增加。
假设随机读延迟在50ms左右为可接受时,那么当此集群Qps达到150000(可能会在多点)时,就需要开始关注RPC.CallQueue的数量,如果只是某台RS的RPC.CallQueue数量比较高,先考虑是否是HotRegion引起的;如果大部分RS的RPC.CallQueue数量一直比较高,就需要考虑添加机器来缓解压力。