完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
摘要:在项目开发过程中,我们经常需要一些benchmark工具来对系统进行压测,以获得系统的性能参数,极限吞吐等等指标。而在HBase中,就自带了一个benchmark工具—PerformanceEvaluation,可以非常方便地对HBase的Put、Get、Scan等API进行性能测试,并提供了非常丰富的参数来模拟各种场景。 简介 在项目开发过程中,我们经常需要一些benchmark工具来对系统进行压测,以获得系统的性能参数,极限吞吐等等指标。而在HBase中,就自带了一个benchmark工具—PerformanceEvaluation,可以非常方便地对HBase的Put、Get、Scan等API进行性能测试,并提供了非常丰富的参数来模拟各种场景。这篇文章,就以HBbase2.0中的PerformanceEvaluation工具为例,给大家讲解一下这款HBase benchmark工具的使用和注意事项 参数介绍 PerformanceEvaluation的全名是org.apache.hadoop.hbase.PerformanceEvaluation. 已经集成在了bin/hbase工具集中。在安装好HBase的机器上,在HBase的安装路径的bin目录下执行hbase pe,加上相应参数,即可运行PE工具(以下简称PerformanceEvaluation为PE)。如果不加任何参数,则会输出PE的帮助信息。
并在最后统计了所有线程的最大持续时间,平均持续时间等等。 2018-05-18 12:07:25,564 INFO [main] hbase.PerformanceEvaluation(507): [RandomWriteTest duration ] Min: 36969ms Max: 40160ms Avg: 38203ms 比较坑的是,PE竟然不会统计所有线程的平均延迟和总的吞吐。。。 随机读测试 RandomReadTest 在进行RandomReadTest之前,需要准备数据。准备数据建议使用SequentialWriteTest。如下面的语句 hbase pe --nomapred --oneCon=true --valueSize=100 --compress=SNAPPY --size=2 --presplit=64 sequentialWrite 64 为啥要用SequentialWriteTest? 这是因为PE写入的行是有规律的。如果传入的是--row=1000,thread数是10,则写入的行总数是1000 x 10 = 10000。在SequentialWrite中,PE会给每个线程设置偏移量,保证0~9999这10000个行(会把所有数字扩展成26位等长的byte数组)一行不差地写入HBase。如果是RandomWriteTest,在每个线程中会随机生成一个0~9999之前的数字写入(--row=1000代表每个线程会写1000次)。由于是随机,会造成中间有些行没有写入,那么在读取测试时,读到的就是空行,影响测试结果。 为啥要用--size而不是--row? --size=2,代表写入2GB数据,具体是多少行PE内部会自己去算。假设我这里填的是--row=1000,线程数是10,那么写入的数据范围是0~9999。当我在做RandomReadTest时,如果需要修改线程数,比如我想测20个线程并行读,那么数据读取的范围将是0~ (1000 * 20 - 1), 很大一部分读是空读!你当然可以根据线程数来调整读测试时row变量的值,使读的整体范围不超过写入的数据范围,但是row的大小影响了整体测试的时间,而统一用size你就啥都不用管了。 RandomReadTest的命令如下: hbase pe --nomapred --oneCon=true --valueSize=100 --size=2 randomRead 100 注意在读测试时不要加表的任何参数,如presplit这些,如果加了会使PE重新建表,之前写入的数据就拜拜了。valueSize和size的值要与准备数据命令中保持一致,PE靠这两个值来算数据的范围和行数。Read测试的输出与Write测试的输出类似。 PE工具存在的问题 PE工具虽然功能已经比较完备,但是使用下来发现还是存在一定的问题的,主要有以下几点: 1. Connection的数目设置只能由oneCon这个参数指定,要么就是一个connection,要么就是每个thread一个connection。当测试的线程数比较多时,就比较尴尬了,如果只用一个connection,connection内部的metaCache等实现都是有锁的,在拿metacache时,线程较多会产生争抢,影响对服务器性能的评估。如果每个thread一个connection更加不可取,每个connection中都会有一个netty的客户端,如果我没记错的话,每个客户端中将会有 2*CPU个worker threads。这在PE运行过程中产生大量的context switch,更加影响性能测试。根据我的测试发现,在开100个thread测试时,如果每个thread开一个connection,测试结果比只用一个connection的要慢10%。Context switch的频率更是10倍以上。 2. 没有multiPut的支持,PE写时使用的BufferedMutator需要靠调整size来决定buffer多少个put再上发。如果我想明确测试batch 5个put请求,batch10个put请求,都比较难实现。 3. 没有统计总体的RT和TPS/QPS,只有按单个thread统计,如果我用100个thread去压服务器,这要我怎么去评估服务器的吞吐…… 针对以上的问题,我对PerformanceEvaluation工具做了一些改进,回馈给了社区,具体大家可以看HBASE-20601这个issue。主要的改进有: 1. 加入multiPut参数,支持设置batch的数量 2. 加入connCount参数,支持设置connection的多少,比如connCount=2,不管多少个thread都会共用这2个connection 3. 支持统计所有线程的平均TPS,平均延迟 4. 一些代码的优化和去重 大家在PE工具的使用过程中还遇到了什么问题,或者有什么不懂的地方,欢迎与我联系。 云端使用 阿里HBase目前已经在阿里云提供商业化服务,任何有需求的用户都可以在阿里云端使用深入改进的、一站式的HBase服务。云HBase版本与自建HBase相比在运维、可靠性、性能、稳定性、安全、成本等方面均有很多的改进, 原文链接 |
|
|
|
只有小组成员才能发言,加入小组>>
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2025-7-20 10:15 , Processed in 0.497836 second(s), Total 70, Slave 51 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191