HBase基准性能测试报告 (2)

1.     吞吐量曲线分析:线程数在10~500的情况下,随着线程数的增加,系统吞吐量会不断升高;之后线程数再增加,系统吞吐量基本上不再变化。结合图3带宽资源使用曲线图可以看出,当线程数增加到一定程度,系统带宽资源基本耗尽,系统吞吐量就不再会增加。可见,HBase写操作是一个带宽敏感型操作,当带宽资源bound后,写入吞吐量基本就会稳定。

 

2.     写入延迟曲线分析:随着线程数的不断增加,写入延迟也会不断增大。这是因为写入线程过多,导致CPU资源调度频繁,单个线程分配到的CPU资源会不断降低;另一方面由于线程之间可能会存在互斥操作导致线程阻塞;这些因素都会导致写入延迟不断增大。

 

建议

根据曲线显示,500线程以内的写入延迟并不大于10ms,而此时吞吐量基本最大,因此如果是单纯写入的话500线程写入会是一个比较合适的选择。

 

单纯查询

测试参数

总记录数为10亿,分为128个region,均匀分布在4台region server上;查询操作执行2千万次;查询请求分布遵从zipfian分布;

测试结果

HBase基准性能测试报告

 

资源使用情况

HBase基准性能测试报告

HBase基准性能测试报告

图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分布;

 

测试结果

HBase基准性能测试报告

资源使用情况

HBase基准性能测试报告

HBase基准性能测试报告

图8为线程数在1000时IO利用率曲线图,图中IO利用率基本保持在100%,说明IO资源已经达到使用上限。图9为线程数在1000时带宽资源使用曲线图,图中带宽资源基本也已经达到上限。

 

结果分析

1.     吞吐量曲线分析:线程数在10~500的情况下,随着线程数的增加,系统吞吐量会不断升高;之后线程数再增加,系统吞吐量基本上不再变化。结合图8 、图9资源使用曲线图可以看出,当线程数增加到一定程度,系统IO资源基本达到上限,带宽也基本达到上限。IO利用率达到100%是因为大量的读操作都需要从磁盘查找数据,而带宽负载很高是因为每次scan操作最多可以获取50Kbyte数据,TPS太高会导致数据量很大,因而带宽负载很高。两者结合导致系统吞吐量就不再随着线程数增大会增大。可见,scan操作是一个IO/带宽敏感型操作,当IO或者带宽资源bound后,scan吞吐量基本就会稳定不变。

 

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wspggw.html