HBase随机读写性能测试

标签: Hadoop&HBase hbase 性能 性能测试 随机读写 | 发表时间:2011-08-16 00:17 | 作者:nosqlfan jiaosq
出处:http://blog.nosqlfan.com

本文转载自淘宝网BlueDavy同学的博客,文章基于淘宝对HBase的大量应用,给出了一个HBase的随机读写性能测试结果,对测试环境、配置及性能参数分析都有较详细的描述,推荐给各位NoSQL Fans。

根据最近生产环境使用的经验,更多的项目的采用,以及采用了更加自动的测试平台,对HBase做了更多的场景的测试,在这篇blog中来分享下纯粹的随机写和随机读的性能数据,同时也分享下我们调整过后的参数。

测试环境说明:

  • 1、Region Server: 5台,12块1T SATA盘(7200 RPM),No Raid,物理内存24G,CPU型号为E5620;启动参数为:-Xms16g -Xmx16g -Xmn2g -XX:SurvivorRatio=2 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=85
  • 2、Data Node:35台,和Region Server同样的硬件配置,启动参数上-Xms2g -Xmx2g,未设置-Xmn;

服务端参数:

  • hbase.replication false
  • hbase.balancer.period 1200000
  • hfile.block.cache.size 0.4,随机读20%命中场景使用0.01
  • hbase.regionserver.global.memstore.upperLimit 0.35
  • hbase.hregion.memstore.block.multiplier 8
  • hbase.server.thread.wakefrequency 100
  • hbase.regionserver.handler.count 300
  • hbase.master.distributed.log.splitting false
  • hbase.regionserver.hlog.splitlog.writer.threads 3
  • hbase.hregion.max.filesize 1073741824
  • hbase.hstore.blockingStoreFiles 20
  • hbase.hregion.memstore.flush.size 134217728

客户端参数:

  • hbase.client.retries.number 11
  • hbase.client.pause 20
  • hbase.ipc.client.tcpnodelay true
  • ipc.ping.interval 3000

最终随机写的测试性能结果如下(点开可看大图):

从写的测试来看,可以看到,当客户端线程数在250左右时,此时的响应时间在6ms左右,tps在7.5k左右,差不多是比较好的一个状态。

在随机写的测试中,以及我们的一些项目的测试中,看到的一些现象和问题:

  • 1、随着单台机器的region数变多了,tps下降的比较明显,team的同事做了一个改进,保障了随着region数的增多,tps基本不会有太多的下降,具体请见同事的这篇blog
  • 2、当hbase.regionserver.handler.count为100(默认为10,更正常了)时,压力大的情况下差不多100个线程都会BLOCKED,增加到300后差不多足够了,此时tps也到达瓶颈了;
  • 3、当datanode数量比较少时,会导致写tps比较低,原因是此时compact会消耗掉太多的网络IO;
  • 4、当写采用gz压缩时,会造成堆外内存泄露,具体请参见同事的这篇blog
  • 5、在压力增大、region数增多的情况下,split和flush会对写的平稳性造成比较大的影响,而通常内存是够用的,因此可以调整split file size和memstore flush size,这个要根据场景来决定是否可调整。

对写的速度影响比较大的因素主要是:请求次数的分布均衡、是否出现Blocking Update或Delaying flush、HLog数量、DataNode数量、Split File Size。

随机读的测试性能结果如下(点开可看大图):

从读的测试来看,可以看到,读的tps随cache命中率降低会下降的比较厉害,命中率为90%时、客户端线程数为250时,此时的响应时间和tps是比较不错的状况。

在随机读的测试中,以及我们的一些项目的测试中,看到的一些现象和问题:

  • 1、随机读的tps随着命中率下降,下降的有点太快,具体原因还在查找和分析中;
  • 2、当命中率很低时,读bloomfilter的索引信息需要耗费掉比较多的时间,主要原因是bloomfilter的索引信息并没有在cache优先级中占优,这是一个可以改进的点。

对读的速度影响比较大的因素主要是:请求次数的分布均衡、StoreFile数量、BloomFilter是否打开、Cache大小以及命中率。

ps: 强烈推荐同事的blog,其中记录了很多我们对HBase的改进,以及我们在运维HBase项目时碰到的各种奇怪、诡异的问题。

来源:blog.bluedavy.com

技术传播,需要你我共同努力!    

相关文章:

LevelDB、TreeDB、SQLite3性能对比测试

性能测试:MongoDB vs. SQL Server

taobao核心系统团队的Cassandra测试结果

MongoDB、HandlerSocket和MySQL性能测试及其结果分析

MongoDB1.6版本与最新1.8版本性能测试——写入篇
无觅

相关 [hbase 随机 性能] 推荐:

HBase随机读写性能测试

- jiaosq - NoSQLFan
本文转载自淘宝网BlueDavy同学的博客,文章基于淘宝对HBase的大量应用,给出了一个HBase的随机读写性能测试结果,对测试环境、配置及性能参数分析都有较详细的描述,推荐给各位NoSQL Fans. 根据最近生产环境使用的经验,更多的项目的采用,以及采用了更加自动的测试平台,对HBase做了更多的场景的测试,在这篇blog中来分享下纯粹的随机写和随机读的性能数据,同时也分享下我们调整过后的参数.

HBase随机写以及随机读性能测试

- d0ngd0ng - BlueDavy之技术blog
根据最近生产环境使用的经验,更多的项目的采用,以及采用了更加自动的测试平台,对HBase做了更多的场景的测试,在这篇blog中来分享下纯粹的随机写和随机读的性能数据,同时也分享下我们调整过后的参数. 1、Region Server: 5台,12块1T SATA盘(7200 RPM),No Raid,物理内存24G,CPU型号为E5620;.

HBase性能调优

- - 学着站在巨人的肩膀上
我们经常看到一些文章吹嘘某产品如何如何快,如何如何强,而自己测试时却不如描述的一些数据. 其实原因可能在于你还不是真正理解其内部结构,对于其性能调优方法不够了解. 本文转自TaoBao的Ken Wu同学的博客,是目前看到比较完整的HBase调优文章. 原文链接:HBase性能调优. 因官方Book Performance Tuning部分章节没有按配置项进行索引,不能达到快速查阅的效果.

hbase性能调优

- - 数据库 - ITeye博客
   1)、hbase.regionserver.handler.count:该设置决定了处理RPC的线程数量,默认值是10,通常可以调大,比如:150,当请求内容很大(上MB,比如大的put、使用缓存的scans)的时候,如果该值设置过大则会占用过多的内存,导致频繁的GC,或者出现OutOfMemory,因此该值不是越大越好.

Hbase 性能优化

- - CSDN博客云计算推荐文章
因 官方Book Performance Tuning部分章节没有按配置项进行索引,不能达到快速查阅的效果. 所以我以配置项驱动,重新整理了原文,并补充一些自己的理解,如有错误,欢迎指正. 默认值:3分钟(180000ms). 说明:RegionServer与Zookeeper间的连接超时时间.

hbase性能优化

- - CSDN博客推荐文章
  当你调用create方法时将会加载两个配置文件:hbase-default.xml and hbase-site.xml,利用的是当前的java类路径, 代码中configuration设置的这些配置将会覆盖hbase-default.xml和hbase-site.xml中相同的配置,如果两个配置文件都存在并且都设置好了相应参上面的属性下面的属性即可.

HBase性能优化

- - zzm
本文主要介绍软件层面的性能调优. 硬盘推荐SSD,一般SATA即可. 可以安装Ganglia等工具,检查各节点的各硬件的运作状态:CPU,Memo,网络等等. 入门级的调优可以从调整参数开始.  设置buffer的容量,例子中设置了6MB的buffer容量. * 必须禁止auto flush. * 6MB是经验值,可以上下微调以适应不同的写场景.

HBase性能深度分析

- Rubby - 《程序员》杂志官网
HBase作为BigTable的一个开源实现,随着其应用的普及,用户对它的性能数据愈发关注. 本文将为您揭开HBase性能测试的一角,邀您一起参与到对云计算模块性能调优的深度思考中. 对于BigTable类型的分布式数据库应用来说,用户往往会对其性能状况有极大的兴趣,这其中又对实时数据插入性能更为关注.

HBase+G1GC性能调优 - HBase 技术社区

- -
目前小米已经在线上开始大规模使用G1垃圾回收算法,在论坛中也看到一些朋友在讨论使用G1碰到的各种各样的问题,这里打算写一篇文章记录下调G1的一些经验.. 先传送门一下,之前在HBaseConAsia2017分享过一个g1gc调优的ppt:http://openinx.github.io/2012/01/01/my-share/ .