博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Hbase 参数配置及优化
阅读量:7132 次
发布时间:2019-06-28

本文共 2829 字,大约阅读时间需要 9 分钟。

From:http://www.open-open.com/lib/view/open1346684547787.html

接触hbase已有半年的时间,查了很多资料,也参考了很多别人心得,也希望把自己的心得以及理解写出来,我把配置hbase必调的几个参数写一下,以及它们的意义。

zookeeper.session.timeout

这个参数的意义是regionserver在zookeeper的会话过期时间,默认是3分钟,如果regionserver 在zookeeper.session.timeout这个配置的时间没有去连zookeeper的话,zookeeper会将该 regionserver在zookeeper摘除,不让该regionserver向提供服务,很多人都该值配置很大,原因是生产环境中 regionserver的内存都配置很大,以扩大memstore和cache的大小,提高性能,但是内存配置大了以后,regionserver在 jvm做一次内存大回收时,时间也会变长,很有可能这个时间超过zookeeper.session.timeout时间,导致regionserver 在jvm回收内存的时候,zookeeper误以为regionserver挂掉而将regionserver摘除。但我认为该值还是不要配的过大,首先地java已支持cms方式回收内存,每次内存回收的时间不是太长,并且生产环境中,我们也不允许过长时间的服务中断,配置大了,容易造成一个 regionserver的服务真出现异常时,zookeeper不会切除该regionserver,使得很多请求失败。

hbase.regionserver.handler.count

regionserver的工作线程数量,默认是10,没有疑问,官方默认值太小,通常都调到100~200之间,提高regionserver性能。

hbase.regionserver.lease.period

regionserer租约时间,默认值是60s,也有点小,如果你的生产环境中,在执行一些任务时,如mapred时出现lease超时的报错,那这个时候就需要去调大这个值了。

hfile.block.cache.size

regionserver cache的大小,默认是0.2,是整个堆内存的多少比例作为regionserver的cache,调大该值会提升查询性能,当然也不能过大,如果你的 hbase都大量的查询,写入不是很多的话,调到0.5也就够了,说到这个值,有一个地方需要说明一下,如果生产环境有mapred任务去scan hbase的时候,一些要在mapred scan类中加一个scan.setCacheBlocks(false),避免由于mapred使用regionserver的cache都被替换,造成hbase的查询性能明显下降。

hbase.hregion.memstore.flush.size

一个regionserver的单个region memstore的大小,默认是64M,在hbase结构中,一个regionserver管理多个region,一个region对应一个hlog和多个store,一个store对应多个storefile和一个memstore,这里的 hbase.hregion.memstore.flush.size意思一个region下面的所有store里面的memstore的达到多少时,开始将这些memstore flush到hdfs中去,配置这个值,需要参考一下,平均每个regionserver管理的region数量,如果每台regionsever管理的 region不多的话,可以适当的调大该值,如512M时再flush。

hbase.regionserver.global.memstore.upperLimit/hbase.regionserver.global.memstore.lowerLimit

配置一台regionserver所有memstore占整个堆的最大比例,默认是0.4/0.35,二个值的差异在于是做局部的flush,还是全部flush,如果你的regionserver日志中,频发出现因为超过 hbase.regionserver.global.memstore.lowerLimit而做flush的信息,我觉得有必要调小 hbase.hregion.memstore.flush.size,或者适当调大这二个值,当然 hbase.regionserver.global.memstore.upperLimit和hfile.block.cache.size的和不能大于1,到0.8我觉得已经够大了。如果你的jvm内存回收是使用cms的话,有一个值 CMSInitiatingOccupancyFraction(内存使用到时多少时,一始cms回收内存)的大小和觉得和这个有关系,略小于 hbase.regionserver.global.memstore.upperLimit和hfile.block.cache.size的和是一个不错的选择。

hbase.hstore.compactionThreshold/hbase.hregion.majorcompaction

hbase.hstore.compactionThreshold执行compaction的store数量,默认值是3,如果需要提高查询性能,当然是storefile的数量越小,性能越好,但是执行compaction本身有性能资源的开消,如果regionserver频繁在 compacion对性能影响也很大。hbase.hregion.majorcompaction表示majorcompaction的周期,默认是1 天,majorcompaction与普通的compaction的区别是majorcompaction会清除过期的历史版本数据,同时合并 storefile,而普通的compaction只做合并,通常都是majorcompaction,调为0,然后手工定期的去执行一下 majorcompaction,适当调小点compacionThreshold。

hbase.hregion.max.filesize

一个regionsever的最大值,默认是256M,如果数据量特别大的话,调大该值可以减少region的数量,调到2G我觉得都不为过。

hbase配置调优太多,jvm,mslab内存管理以及hdfs append方式等等,需要太多的知识面,很多东西,我也在学习之中,先写这么多。

  先引荐别人的,其后将不断更新。

转载于:https://www.cnblogs.com/wq920/p/3998170.html

你可能感兴趣的文章
poj 1852
查看>>
form的method用get导致中文乱码
查看>>
android Mediaplayer各种属性和方法简单介绍
查看>>
非阻塞同步机制与CAS操作
查看>>
给明年依然年轻的我们
查看>>
再次写给我们这些浮躁的程序员
查看>>
[C] c99int(让VC等编译器自动兼容C99的整数类型)V1.02。源码托管到github、添加CMake编译配置文件、使用doxygen规范注释...
查看>>
python 编码 UnicodeDecodeError
查看>>
(面试题)类的初始化顺序
查看>>
Linux设备驱动剖析之IIC(一)
查看>>
Ext面板
查看>>
leverage准确翻译,译法,英文
查看>>
2013年9月1日下午
查看>>
Linux下编写 makefile 详细教程
查看>>
Python编码/文件读取/多线程
查看>>
nyoj------------找球号(一)
查看>>
Git SSH Key 生成步骤
查看>>
BI失败的原因
查看>>
eaccelerator 完全手册:配置、控制、API接口
查看>>
负载均衡--大型在线系统实现的关键(上篇)(再谈QQ游戏百万人在线的技术实现)...
查看>>