Hbase性能优化之配置

标签: hbase 性能优化 | 发表时间:2013-05-13 17:16 | 作者:花考拉
出处:http://www.cnblogs.com/

减少zk超时时间(建议1分钟)

Rs与zk的timeout默认为3分钟,由zookeeper.session.timeout property决定。也就是说,如果一个rs挂了,那么master需要3分钟之后才能对其进行重启和恢复。建议调成1分钟会更低。

然而,你调低之前应该先确保JVM的配置合理,保证不会引发较长的gc,JVM配置之后会给出,也可以只这样,只要你超时时间可以忍受gc停顿即可。

 

增加handlers(建议100)

配置项 hbase.regionserver.handler.count 决定了用户表接受外来请求的线程数。默认为10。这个数目主要看你的场景。如果是put百万字节或者大量的scan你可以把它调低来减少对region的压力。如果是小的puts gets 则增加该值来挺高并发量。从而增加整体的吞吐。

Handler数量最好小于clinet并发量。一个典型场景就是多gets(可能是个网站,然后从hbase获取数据)。

调高之后的风险就是,一旦很多的并发写压到了一个rs上面,那么内存会陡增,可能引发OOM。另外,rs的内存不足会引发较长的gc停顿。

 

增加heap(稍好的8G,差点的自己定吧)

对于hbase当然是越大约好,因为他就是吃内存的东西。稍微好点的机器可以给8G,master相比rs不需要更多的内存,但是rs一定需要。

 

开启Lzo压缩

 

增加region的大小(100G,几乎永不分裂)

 选项hbase.hregion.max.filesize默认为256M,如果region大小超过他则会分裂为二,如果你的数据量增长的比较快,那么还是建议把这个大小调高,可以调成100G,因为越少的region你的集群越流畅,100G的阈值基本可以避免你的region增长过快,甚至你的region数目会长期不变。当然大region在compaction时也会更加缓慢。几十G的region启动和compaction都非常的慢,如果storefile较多,一个compaction可能会持续几天。

 

block cache size(读写平衡0.3)

选项perf.hfile.block.cache.size 默认是0.2。调优这个参数需要你自己的观察,可以参照HBase权威指南的394页。

其实常见场景还是读业务比较多的时候可以把它调高。这样可以缓存更多的数据。读写平衡可以设置为0.3。

需要注意的是,block.cache.size memstore limits 这些内存加起来不要超过60%。因为剩余的内存还要用来做其他事情。否则容易OOM。

 

memstore limits(写多则调高,读多则调低)

这里主要由两个配置项决定:hbase.regionserver.global.memstore.upper 默认0.4和hbase.region.server.global.memstore.lowerLimit默认0.35。后者主要是当服务器需要释放内存时强制rs进行flush(不一定达到flush size)。尽量保证上面两个值接近,这样可以避免频繁的flush。

如果你的读业务比较多,那么调低他们。如果写多,则调高他们。(注意读写的参数相加最好不要超过0.6)。如果你发现flush很频繁,那么调高上面两个配置,这样减少频繁的I/O。

 

调高blocking store files(10)

选项hbase.hstore.blockingStoreFiles默认为7,如果超过其设定阈值,则会阻塞client的写。它主要是为了给compaction更多的时间来减少store files的数量。如果你是持续写入,那么稍微调高一点,比如10。你可以观察rs的storefile的数量,如果数量一直比较高,那么就不要把这个阈值调高了。因为持续很多的sf会让机器一直compaction,造成的一种情况就是compaction和flush的速度不匹配,然后持续的堆积compaction的任务,rs和dn的连接数会越来越大,直到too many open files。

 

调高block multiplier(稳定数据写入不必调正,数据量比较大或者偶尔出现峰值则调高)

选项hbase.hregion.memstore.block.multiplier默认为2。它是一种安全机制,如果memstores超过了flushsize的multiplier倍则会阻塞客户端的写。

如果你有足够多的内存,那么你可以把它调高,这样的好处就是可以很好的处理峰值的情况。比如一天可能只有一个时间段内写量很大,那么调高之后就可以避免阻塞写操作了。

 

减少maximum logfiles(导入数据直接关闭WAL即可,写多则调高,一般情况下小一点比较好)

选项hbase.regionserver.maxlogs默认为32。它只要是控制WAL文件flush的频率。如果写操作比较多,那么可以设置高一点。调低可以让rs更快的把数据持久化,那么就可以直接弃掉WAL了。其实写操作比较多可以直接把WAL关闭,这样更省事了。

本文链接

相关 [hbase 性能优化] 推荐:

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性能优化之配置

- - 博客园_首页
减少zk超时时间(建议1分钟). Rs与zk的timeout默认为3分钟,由zookeeper.session.timeout property决定. 也就是说,如果一个rs挂了,那么master需要3分钟之后才能对其进行重启和恢复. 然而,你调低之前应该先确保JVM的配置合理,保证不会引发较长的gc,JVM配置之后会给出,也可以只这样,只要你超时时间可以忍受gc停顿即可.

HBase性能优化方法总结

- - IT技术博客大学习
标签:   HBase.     本文主要是从HBase应用程序设计与开发的角度,总结几种常用的性能优化方法. 有关HBase系统配置级别的优化,这里涉及的不多,这部分可以参考: 淘宝Ken Wu同学的博客.     默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据,直到这个region足够大了才进行切分.

Hbase性能优化 - 季石磊

- - 博客园_stanley's blog
以下为使用hbase一段时间的几个思考,由于在内存充足的情况下hbase能提供比较满意的读性能,因此写性能是思考的重点.     无论是官方还是很多blog都提倡为了提高hbase的写入速度而在应用代码中设置autoflush=false,然后在在线应用中应该谨慎进行该设置.     a autoflush=false的原理是当客户端提交delete或put请求时,将该请求在客户端缓存,直到数据超过2M(hbase.client.write.buffer决定)或用户执行了hbase.flushcommits()时才向regionserver提交请求.

HBase最佳实践-写性能优化策略 – 有态度的HBase/Spark/BigData

- -
上一篇文章主要介绍了HBase读性能优化的基本套路,本篇文章来说道说道如何诊断HBase写数据的异常问题以及优化写性能. 和读相比,HBase写数据流程倒是显得很简单:数据先顺序写入HLog,再写入对应的缓存Memstore,当Memstore中数据大小达到一定阈值(128M)之后,系统会异步将Memstore中数据flush到HDFS形成小文件.

HBase最佳实践-读性能优化策略 – 有态度的HBase/Spark/BigData

- -
任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题. HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是HBase还需要完善的,有些是我们确实对它了解太少. 总结起来,大家遇到的主要问题无非是Full GC异常导致宕机问题、RIT问题、写吞吐量太低以及读延迟较大.

Pora2应用中HBase高并发读写性能优化

- - 搜索技术博客-淘宝
淘宝搜索的个性化离线实时分析系统Pora已升级至Pora2,Pora2是在基于Yarn的流式计算框架IStream基础上开发的,同时为保证数据和消息的实时处理系统中较多地使用了HBase,是一个典型的高并发读写HBase的分布式应用. 系统在发布之初遇到了比较严重的性能问题,表现为处理速度跟不上实时日志,并且整个Hadoop/HBase集群压力大,连带其它应用受影响.