当前位置:首页 > 开发 > 系统架构 > 架构 > 正文

hbase 配置优化

发表于: 2015-06-06   作者:blackproof   来源:转载   浏览次数:
摘要: hbase的优化的一点经验,一直没做这个笔记,是因为hbase自身也有设计缺陷,所以有些配置不能说优化,只能说因为hbase自身缺陷可以将就着用,不说废话了,以下就是优化的一点笔记   hbase配置修改: (split是因为hfile过多,进行split,split之后进行compact   可以可能要有人喷了,hfile多了应该compact才对啦。贴出0.98.1

hbase的优化的一点经验,一直没做这个笔记,是因为hbase自身也有设计缺陷,所以有些配置不能说优化,只能说因为hbase自身缺陷可以将就着用,不说废话了,以下就是优化的一点笔记

 

hbase配置修改:

(split是因为hfile过多,进行split,split之后进行compact  

可以可能要有人喷了,hfile多了应该compact才对啦。贴出0.98.1的代码,大致逻辑是region没有block的compact(优先级大于等于1的),则进行split)

 private boolean flushRegion(final FlushRegionEntry fqe) {
    HRegion region = fqe.region;
    if (!region.getRegionInfo().isMetaRegion() &&
        isTooManyStoreFiles(region)) {//这个函数使用了参数
      if (fqe.isMaximumWait(this.blockingWaitTime)) {
        LOG.info("Waited " + (System.currentTimeMillis() - fqe.createTime) +
          "ms on a compaction to clean up 'too many store files'; waited " +
          "long enough... proceeding with flush of " +
          region.getRegionNameAsString());
      } else {
        // If this is first time we've been put off, then emit a log message.
        if (fqe.getRequeueCount() <= 0) {
          // Note: We don't impose blockingStoreFiles constraint on meta regions
          LOG.warn("Region " + region.getRegionNameAsString() + " has too many " +
            "store files; delaying flush up to " + this.blockingWaitTime + "ms");
          if (!this.server.compactSplitThread.requestSplit(region)) {//这里是关键的逻辑,逻辑是region没有block的compact(优先级大于等于1的),则进行split;否则进行compact
            try {
              this.server.compactSplitThread.requestSystemCompaction(
                  region, Thread.currentThread().getName());
            } catch (IOException e) {
              LOG.error(
                "Cache flush failed for region " + Bytes.toStringBinary(region.getRegionName()),
                RemoteExceptionHandler.checkIOException(e));
            }
          }
        }

        // Put back on the queue.  Have it come back out of the queue
        // after a delay of this.blockingWaitTime / 100 ms.
        this.flushQueue.add(fqe.requeue(this.blockingWaitTime / 100));
        // Tell a lie, it's not flushed but it's ok
        return true;
      }
    }
    return flushRegion(region, false);
  }

 

hbase.hstore.blockingStoreFiles hfile数量上限,如果超过,则进行阻塞写,进行split | compact

 

hbase.hstore.blockingWaitTime 阻塞写的时间上限 ,到时间没进行split或compact(就是没锁上,则继续)

 

最大region 500G,禁止常规的split情况

 

 <property>

 <name>hbase.hregion.max.filesize</name>

 <value>536870912000</value>

 </property>

 

 一个store中30个hfile的上限

 

 <property>

<name>hbase.hstore.blockingStoreFiles</name>

<value>30</value>

 </property>

 

 

 一分半的写的阻塞上限

 

<property>

<name>hbase.hstore.blockingWaitTime</name>

<value>90000</value>

</property>

 

 

 

 

 hbase.regionserver.regionSplitLimit region包含的最大region数, split需要检查现有region不大于这个

 

 compact Priority逻辑

 初始化为int.minvalue,user为1,被block>1

 

 

 -----------------------------------------------

  DEBUG [LruStats #0] hfile.LruBlockCache: Total=11.78 GB, free=1.01 GB, max=12.79 GB,

 memcache设置256

 memcache使用mslb

 

使用mslb

 

<property>

<name>hbase.hregion.memstore.mslab.enabled</name>

<value>true</value>

</property>

 

memcash的flush的条件256M

 

<property>

<name>hbase.hregion.memstore.flush.size</name>

<value>268435456</value>

</property>

 

安全检查memstore使用region_heap的百分比 , 强制flush

 

</property> 

base.regionserver.global.memstore.lowerLimit 

<property> 

    <name>hbase.regionserver.global.memstore.lowerLimit</name> 

    <value>0.36</value> 

    <description> 

        一个RS中所有的memstore的总容量超过堆的该百分比限制后,将被强制flush到磁盘。 

        Maximum size of all memstores in a region server before flushes are forced. Defaults to 35% of heap. 这个值与 

        hbase.regionserver.global.memstore.upperLimit相等,以减小由于到达该值触发flush的几率,因为这种flush会block写请求 

    </description> 

</property> 

 

安全检查memstore使用region_heap的百分比 , 强制flush,并阻塞写请求

 

<property> 

    <name>hbase.regionserver.global.memstore.upperLimit</name> 

    <value>0.4</value> 

    <description> 

        一个region中所有memstore的总大小超过堆的该百分比限制时,会发生强制flush,并block更新请求。 

        默认是堆大小的40%。更新会被阻塞,并发生强制flush,直到所有memstore的大小达到 

        hbase.regionserver.global.memstore.lowerLimit的限制。 

    </description> 

</property> 

 

达到flushsize指定倍数时,会强制flush,并阻塞请求

 

<property> 

    <name>hbase.hregion.memstore.block.multiplier</name> 

    <value>2</value> 

    <description> 

        当一个region的memstore达到hbase.hregion.memstore.block.multiplier * hbase.hregion.flush.size的指定倍数时,阻塞写请求。 

        这是一个避免在写请求高峰时期避免memstore耗尽的有效设置。如果没有上限限制,memstore被填满后发生flush时, 

        会消耗大量的时间来处理合并和分割,甚至导致OOM。 

    </description> 

</property> 

 

----------------------------------------------------

 

 

 gc的问题

  3.5分钟挂掉

  11 分钟

 

 (70)提前gc,减少每个gc耗时

 

 hbase-env.sh中

 

 export HBASE_REGIONSERVER_OPTS="-Xmx16g -Xms16g -Xmn128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:$HBASE_HOME/logs/gc-hbase.log"

 

 

 

 ----------------------------------------------------

 

 compact时间是否过长??

 

 compact的时候gc过长

 

2015-02-25 11:54:50,670 WARN  [regionserver60020.periodicFlusher] util.Sleeper: We slept 565427ms instead of 10000ms, this is likely due to a long garbage collecting pause and it's usually bad, se

e http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired

2015-02-25 11:54:50,670 WARN  [DataStreamer for file /hbase/WALs/host64,60020,1422073827259/host64%2C60020%2C1422073827259.1424835178059 block BP-1540478979-192.168.5.117-1409220943611:blk_1097821

214_24084365] hdfs.DFSClient: Error Recovery for block BP-1540478979-192.168.5.117-1409220943611:blk_1097821214_24084365 in pipeline 192.168.5.64:50010, 192.168.5.95:50010: bad datanode 192.168.5.

64:50010

2015-02-25 11:54:50,670 WARN  [regionserver60020.compactionChecker] util.Sleeper: We slept 565427ms instead of 10000ms, this is likely due to a long garbage collecting pause and it's usually bad,

see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired

2015-02-25 11:54:50,670 INFO  [regionserver60020-SendThread(host141:42181)] zookeeper.ClientCnxn: Client session timed out, have not heard from server in 577669ms for sessionid 0x44add78c8664fdb,

closing socket connection and attempting reconnect

 

 

 转为手动compact,需要逐步手动compact

 <property>

<name>hbase.hregion.majorcompaction</name>

<value>0</value>

</property>

 

------------------------------------------------------

 

 

regionserver里的handler数量 50

 

<property>

<name>hbase.regionserver.handler.count</name>

<value>50</value>

<source>hbase-site.xml</source>

</property>

 

 

--------------------------------------------------

 

wal大小,影响memcash flush

当前hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs   128*32=4G

但是hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE   0.38*32=12.16G

    hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE   0.4*32=12.8

    注意:确保hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs 比hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE的值只高那么一点点。. 

 

改为

 

<property>

<name>hbase.regionserver.maxlogs</name>

<value>104</value>

</property>

 

<property>

<name>hbase.regionserver.global.memstore.lowerLimit</name>

<value>0.36</value>

</property>

 

 

128*105=13G

0.36*32=11.52G

0.4*32=12.8G

 

原则是让memflush不阻塞,禁止因为wal触发的flush,wal会进行多region flush,并且阻塞,这是最坏的情况

 

 

 

---------------------------------------------------

 

blockcache是读取时使用内存

 

<property>
<name>hfile.block.cache.size</name>
<value>0.4</value>
</property>

 

 

 

----------------------------------------------------

 

超时时间待验证,设置或过长

 

<property>
       <name>hbase.rowlock.wait.duration</name>
       <value>90000</value>
       <description> 
        每次获取行锁的超时时间,默认为30s
       </description> 
</property>
<property>
			<name>hbase.regionserver.lease.period</name>
			<value>180000</value>
			<description> 
			客户端每次获得rs一次socket时间
			</description> 
</property>

<property>
       <name>hbase.rpc.timeout</name>
       <value>180000</value>
			<description> 
			rpc超时时间
			</description> 
</property>

<property>
       <name>hbase.client.scanner.timeout.period</name>
       <value>180000</value>
			<description> 
			客户端每次scan|get的超时时间
			</description> 
</property>

<property>
        <name>hbase.client.scanner.caching</name>
        <value>100</value>
			<description> 
			客户端每次scan的一个next,获得多少行,默认1
			</description> 
</property>

 

 

 

 

 

hbase 配置优化

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
使用hbase的目的是为了海量数据的随机读写,但是在实际使用中却发现针对随机读的优化和gc是一个很大
使用hbase的目的是为了海量数据的随机读写,但是在实际使用中却发现针对随机读的优化和gc是一个很大
1、为何要 BulkLoad 导入?传统的 HTableOutputFormat 写 HBase 有什么问题? 我们先看下 HBase 的
我们在用hbase的api对hbase进行scan操作的时候,可以设置caching和batch来提交查询效率,那它们之间
HBase 是一个开源的非关系(NoSQL)的可伸缩性分布式数据库。它是面向列的,并适合于存储超大型松散数
HBase入门笔记(四)--完全分布式HBase集群安装配置 - 林场 - 博客园 HBase入门笔记(四)--完全分
1.安装软件 OS:centos6.5 Hadoop:hadoop2.6.0 Hbase:hbase.1.0.0 JDK: jdk1.7.0_51 集群机器: 192
1.安装软件 OS:centos6.5 Hadoop:hadoop2.6.0 Hbase:hbase.1.0.0 JDK: jdk1.7.0_51 集群机器: 192
淘宝搜索的个性化离线实时分析系统Pora已升级至Pora2,Pora2是在基于Yarn的流式计算框架IStream基础
1、HBase 简介 HBase —— Hadoop Database的简称,Google BigTable的另一种开源实现方式,从问世之
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号