HBase性能调优

标签: hbase性能调优
12人阅读 评论(0) 收藏 举报
分类:

Hbase调优

 

Region拆分和合并

进行预分区,从而避免自动split ,降低hbase相应速度。

如果米有提前创建分区,那么建表的时候,只有一个分区,只有一个region

数据不断往里面写,当达到一定阈值的时候,region一分为二。会出现热点现象

服务端调优

1、Hbase 常见参数调优配置

 


1hbase.hregion.majorcompaction

配置major合并的间隔时间,默认为1天,可设置为0,禁止自动的major合并,可手动或者通过脚本定期进行major合并,有两种compactminormajorminor通常会把数个小的相邻的storeFile合并成一个大的storeFileminor不会删除标示为删除的数据和过期的数据,major会删除需删除的数据,major合并之后,一个store只有一个storeFile文件,会对store的所有数据进行重写,有较大的性能消耗。

2hbase.regionserver.handler.count

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

3hbase.hregion.max.filesize 

配置region大小,0.94.12版本默认是10Gregion的大小与集群支持的总数据量有关系,如果总数据量小,则单个region太大,不利于并行的数据处理,如果集群需支持的总数据量比较大,region太小,则会导致region的个数过多,导致region的管理等成本过高,如果一个RS配置的磁盘总量为3T*12=36T数据量,数据复制3份,则一台RS服务器可以存储10T的数据,如果每个region最大为10G,则最多1000region,如此看,94.12的这个默认配置还是比较合适的,不过如果要自己管理split,则应该调大该值,并且在建表时规划好region数量和rowkey设计,进行region预建,做到一定时间内,每个region的数据大小在一定的数据量之下,当发现有大的region,或者需要对整个表进行region扩充时再进行split操作,一般提供在线服务的hbase集群均会弃用hbase的自动split,转而自己管理split

4file.block.cache.size

RSblock cache的内存大小限制,默认值0.25,在偏向读的业务中,可以适当调大该值,具体配置时需试hbase集群服务的业务特征,结合memstore的内存占比进行综合考虑。

 

5hbase.hstore.compactionThreshold

HStorestoreFile数量>= compactionThreshold配置的值,则可能会进行compact,默认值为3,可以调大,比如设置为6,在定期的major compact中进行剩下文件的合并。

6 hbase.hstore.blockingStoreFiles

HStorestoreFile的文件数大于配置值,则在flush memstore前先进行split或者compact,除非超过hbase.hstore.blockingWaitTime配置的时间,默认为7,可调大,比如:100,避免memstore不及时flush,当写入量大时,触发memstoreblock,从而阻塞写操作。

7hbase.hregion.memstore.block.multiplier

默认值2,如果memstore的内存大小已经超过了

hbase.hregion.memstore.flush.size2倍,则会阻塞memstore的写操作,直到降至该值以下,为避免发生阻塞,最好调大该值,比如:4,不可太大,如果太大,则会增大导致整个RSmemstore内存超过memstore.upperLimit限制的可能性,进而增大阻塞整个RS的写的几率。如果region发生了阻塞会导致大量的线程被阻塞在到该region上,从而其它region的线程数会下降,影响整体的RS服务能力

8hbase.hregion.memstore.flush.size

默认值128M,单位字节,超过将被flushhdfs,该值比较适中,一般不需要调整。

9hbase.regionserver.global.memstore.upperLimit

默认值0.4RS所有memstore占用内存在总内存中的upper比例,当达到该值,则会从整个RS中找出最需要flushregion进行flush,直到总内存比例降至该数限制以下,并且在降至限制比例以下前将阻塞所有的写memstore的操作,在以写为主的集群中,可以调大该配置项,不建议太大,因为block cachememstore cache的总大小不会超过0.8,而且不建议这两个cache的大小总和达到或者接近0.8,避免OOM,在偏向写的业务时,可配置为0.45memstore.lowerLimit保持0.35不变,在偏向读的业务中,可调低为0.35,同时memstore.lowerLimit调低为0.3,或者再向下0.05个点,不能太低,除非只有很小的写入操作,如果是兼顾读写,则采用默认值即可。

 

hbase.hregion.memstore.flush.size 这个参数的作用是当单个Region内所有的memstore大小总和超过指定值时,flushregion的所有memstoreRegionServerflush是通过将请求添加一个队列,模拟生产消费模式来异步处理的。那这里就有一个问题,当队列来不及消费,产生大量积压请求时,可能会导致内存陡增,最坏的情况是触发OOM。这个参数的作用是防止内存占用过大,当ReigonServer内所有regionmemstores所占用内存总和达到heap[40%]时,HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存

10hbase.regionserver.global.memstore.lowerLimit

默认值0.35RS的所有memstore占用内存在总内存中的lower比例,当达到该值,则会从整个RS中找出最需要flushregion进行flush,配置时需结合memstore.upperLimitblock cache的配置。

 

upperLimit,只不过lowerLimit在所有regionmemstores所占用内存达到Heap[35%]时,不flush所有的memstore。它会找一个memstore内存占用最大的region,做个别flush,此时写更新还是会被blocklowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。在日志中,表现为 “** Flush thread woke up with memory above low water.”

 

11、hfile.block.index.cacheonwrite

index写入的时候允许put无根(non-root)的多级索引块到block cache里,默认是false,设置为true,或许读性能更好,但是是否有副作用还需调查。

12、io.storefile.bloom.cacheonwrite

默认为false,需调查其作用。

13、hbase.regionserver.regionSplitLimit

控制最大的region数量,超过则不可以进行split操作,默认是Integer.MAX,可设置为1,禁止自动的split,通过人工,或者写脚本在集群空闲时执行。如果不禁止自动的split,则当region大小超过hbase.hregion.max.filesize时会触发split操作(具体的split有一定的策略,不仅仅通过该参数控制,前期的split会考虑region数据量和memstore大小),每次flush或者compact之后,regionserver都会检查是否需要Splitsplit会先下线老region再上线split后的region,该过程会很快,但是会存在两个问题:1、老region下线后,新region上线前client访问会失败,在重试过程中会成功但是如果是提供实时服务的系统则响应时长会增加;2split后的compact是一个比较耗资源的动作。

16Jvm调整

       a、内存大小:master默认为1G,可增加到2Gregionserver默认1G,可调大到10G,或者更大,zk并不耗资源,可以不用调整;

b.垃圾回收

2、其它调优

  1、列族、rowkey要尽量短,每个cell值均会存储一次列族名称和rowkey,甚至列名称也要尽量短,以下截图是表test2的数据和存入hdfs后的文件内容: 



 

Hbase 在资源紧张时降低IO的手段

以下优化手段的前提:

1. 一切都是瓶颈的时(内存,cpuIO,所有手段作用都不大

2. 没有绝对的有效手段,必须针对业务场景去分析

3. 大多数情况下,都是磁盘IO存在问题(CPU和内存其实问题不大,除非配置太差)

 

优化分类

表设计



Rowkey设计

  

读写操作

 

数据角度

 

 

Hbase 本身

 

资源紧张的情况下如何保证最近写入数据查询


 

参考博文

HBase优化总结

https://blog.csdn.net/yonghutwo/article/details/44217685

HBASE性能调优

https://blog.csdn.net/xiefu5hh/article/details/52853881

查看评论

HBASE性能调优

一、服务端调优  1、参数配置    1)、hbase.regionserver.handler.count:该设置决定了处理RPC的线程数量,默认值是10,通常可以调大,比如:150,当请求内容...
  • xiefu5hh
  • xiefu5hh
  • 2016-10-18 22:32:04
  • 1142

hbase性能优化

  • 2017年10月19日 18:39
  • 614KB
  • 下载

HBase性能调优(1.2官方文档)

HBase性能调优 一. 操作系统: 1.内存: 内存尽可能的大,不要饿着HBase。 2.64-bit 使用64位的操作系统。 3.Swapping 当心交换。swappiness设置...
  • GK_kk
  • GK_kk
  • 2017-06-29 11:42:05
  • 1103

关于近期HBase系统设计开发和性能调优的一些小结

1. 全局查询策略 应该一边倒地依赖索引进行查询,保证绝大多数的查询是秒级返回。尽量避免动用全表扫描,让全表扫描仅服务于非常有限的“生僻”查询!实现这种格局需要尽可能地保证索引轻量短小(尽量缩短字节)...
  • bluishglc
  • bluishglc
  • 2014-01-27 12:01:28
  • 9325

HBase性能优化完全版

近期在处理HBase的业务方面常常遇到各种瓶颈,一天大概一亿条数据,在HBase性能调优方面进行相关配置和调优后取得了一定的成效,于是,特此在这里总结了一下关于HBase全面的配置,主要参考我的另外两...
  • u014297175
  • u014297175
  • 2015-08-25 17:11:21
  • 4490

HBase在淘宝主搜索的Dump中的性能调优

  • 2013年03月25日 20:20
  • 2KB
  • 下载

HBase 性能调优

因官方Book Performance Tuning部分章节没有按配置项进行索引,不能达到快速查阅的效果。所以我以配置项驱动,重新整理了原文,并补充一些自己的理解,如有错误,欢迎指正。 配置优化 ...
  • lxpbs8851
  • lxpbs8851
  • 2012-07-30 17:06:32
  • 1597

hbase读写性能测试调优_初稿

Hbase读写性能测试调优    日期 版本 修订 审批 修订说明 2016.9.23 1.0 章鑫 ...
  • zx8167107
  • zx8167107
  • 2017-12-08 17:08:59
  • 710

利用ycsb测试hbase性能

java 、maven、ycsb 的安装及配置见这篇博客: http://blog.csdn.net/hs794502825/article/details/17309845 本篇博客主要介绍...
  • hs794502825
  • hs794502825
  • 2013-12-16 13:52:18
  • 8489

一次对HBase协处理器的内存耗尽问题的GC分析和解决

基于HBase协处理器,将数据建立索引到Elasticsearch,出现的process jvm内存耗尽问题...
  • cmdssd1
  • cmdssd1
  • 2016-06-28 14:51:44
  • 1040
    个人资料
    持之以恒
    等级:
    访问量: 6542
    积分: 1081
    排名: 4万+
    文章存档