美文网首页
HBase性能调优之参数探究(一)

HBase性能调优之参数探究(一)

作者: Moon_魔宽 | 来源:发表于2019-01-06 20:31 被阅读0次

    版权声明:本文为博主原创文章,未经博主允许不得转载。https://www.jianshu.com/p/84824af0ebd7

    【1、zookeeper.session.timeout】

    regionserver在zookeeper的会话过期时间。

    如果regionserver在zookeeper.session.timeout配置的会话时间期内没有去连zookeeper,zookeeper会将该regionserver从zookeeper中摘除,该regionserver停止服务。

    该值不能配置太小,原因是生产环境的regionserver内存都配置很大(256g),可以提高memstore和cache的大小,提高性能。但会引发新的潜在问题,regionserver内存配置大了后,jvm的内存回收时间也会变长,很有可能超过zookeeper.session.timeout参数值,导致zookeeper误认为regionserver挂掉而将该regionserver摘除。

    该值也不能配置太大,首先java已支持g1gc方式回收内存,每次内存回收时间不会很长;其次生产环境不允许长时间的服务中断,该值若配置大了,容易造成一个regionserver服务真发生异常时,zookeeper不会摘除该regionserver,导致很多请求失败。

    zookeeper.session.timeout目前生产环境配置为是1分钟,可调整为3分钟。

    【2、hbase.regionserver.handler.count】

    Regionserver能够处理的IO请求线程数。

    该参数与内存息息相关。对于单次请求内存消耗较高的Big Put场景(大容量单次PUT或设置了较大cache的scan,均属于Big PUT)或regionserver内存紧张的情况,该值可以设置的小一些。

    而对于单次请求内存消耗低,TPS要求很高的场景,可以设置相对大些,100~200,以提高regionserver性能。

    hbase.regionserver.handler.count目前生产值是30,较小,可调整为100。

    【3、file.block.cache.size】

    heap内存的多少比例作为regionserver的cache,默认0.2。该值直接影响读性能。

    还是要看场景,如果读比写多很多,该值设置在0.4~0.5足矣;如果读写均衡,0.3左右差不多;如果写比读多,就直接采用默认值0.2。

    设置该值时还需同时考虑hbase.regionserver.global.memstore.upperLimit参数,该值是memstore占用heap的最大百分比,后面会讲,两个参数一个影响读,一个影响写,两值的和不能超过0.8,不然会有OOM风险。

    目前生产这俩值都是0.4。

    【4、hbase.hregion.max.filesize】

    regionserver上单个region的最大存储空间。当单个region超过该值时,就会触发Region的split,拆分成更小的region。

    HBase中数据一开始会写入memstore,当memstore大小达到一定阈值后,会flush到disk上而成为storefile。当storefile数量超过3时,会启动compaction过程将它们合并为一个storefile。这个过程中会删除一些timestamp过期的数据。而当合并后的storefile大小大于hfile默认的最大值时,会触发split动作,将它切分成两个region。

    当hbase.hregion.max.filesize比较小时,好处是拆分region或compaction小region里的storefile速度很快,内存占用低,缺点是触发split的几率大,平均吞吐量也越大,而spilt的时候region会被offline,因此在split结束前,访问该region的请求将被block(阻止)。当大量的region同时发生split时,系统的整体访问服务将受到严重影响,因此该值若比较小会容易出现吞吐量及响应时间延迟现象。

    当hbase.hregion.max.filesize比较大时,单个region中触发split的几率就变小了,大量region同时触发split的几率也较小,因此吞吐量较hfile.size小尺寸更加稳定些。但也不是没有缺憾,由于该值较大,region长期得不到spilt,做一次compact和split会产生较长时间的停顿,对应用的读写性能冲击非常大。另外,大region意味着较大的storefile,compaction时对内存也是一个挑战。

    hbase.hregion.max.filesize默认值是256M,目前生产上配置的值是20G,该值是一个比较难达到的值,从某种程度上间接禁用了自动split,那么在需要做split时,选择一个访问量较低的时间点,进行手动spit,就能保证绝大多数时间平稳的读写性能。

    【5、hbase.regionserver.global.memstore.upperLimit/hbase.regionserver.global.memstore.lowerLimit】

    默认值:0.4/0.35

    当单个region内所有memstore大小总和超过hbase.hregion.memstore.flush.size值时,会flush该region的所有memstore。Regionserver的flush是通过将请求添加一个队列,模拟生产消费模式来异步处理的,那么当队列来不及消费,产生大量积压请求时,可能会触发OOM。

    upperlimit:该参数的作用就是为了防止内存占用过大,当regionserver内所有region的memstore占用内存总和达到heap的40%时,HBase会强制block所有更新并flush这些reion以释放所有memstore占用的内存。

    lowerlimit:与upperlimit不同的地方在于,当regionserver内所有region的memstore占用内存总和达到heap的35%而非40%时,不flush所有的memstore。它会找一个memstore内存占用最大的region,做个别的flush。该值相当于是在所有region强制flush导致性能下降前的一道防线。在日志中关键字为"**Flush thread woke up with memory above low water"。

    这俩值在生产上的配置为0.4/0.38,其中lowerLimit参数在CDH5.8之前的默认值是0.38,但是在CDH5.8~CDH5.9.1.3参数的意义发生了修改,需要乘以hbase.regionserver.global.memstore.upperLimit才为实际使用到heap的百分比值,那么为了保证使用到heap的38%触发flush,该值需调整到0.95。(0.4*0.95=0.38)

    【6、hbase.hstore.compactionThreshold/hbase.hregion.majorcompaction】

    hbase.hstore.compactionThreshold:执行compaction的storefile数量,默认是3。该值越小查询性能越好,但越小意味着compaction会更加频繁,而compaction本身也会花销资源。

    hbase.hregion.majorcompaction:major compaction的周期,默认是7天。可设置为0,即禁止自动的major合并,可手工或通过脚本定期进行major合并,目前生产便是这么做的。major compaction与mini compaction的区别是major compaction会清除过期的历史版本数据,同时合并storefile,而mini compaction只做合并。

    【7、hbase.regionserver.hlog.blocksize/hbase.regionserver.maxlogs】

    当写数据时默认会在写memstore同时写入Write-ahead Log(WAL)。WAL中包含了所有已经写入Memstore但还未Flush到HFile的更改(edits)。

    当memstore中数据还没有持久化而regionserver宕掉的时候,可以使用WAL进行数据恢复。当WAL变得很大的时候,恢复就需要更长的时间。因此,对WAL的大小会进行限制,当达到限制大小时,就会触发memstore的flush。

    WAL的最大值由hbase.regionserver.hlog.blocksize*hbase.regionserver.maxlogs决定。一旦达到这个值,memstroe flush就会被触发。

    由此可见,memstore flush的触发条件除了memstore.lowerLimit*heap,还有hlog.blocksize*hbase.regionserver.maxlogs。

    一般来说,hbase在region达到128M时应自动触发flush,而目前从Regionserver Flush Queue Size可看到每个regionserver都在每隔1个半小时进行flush,(理想情况下,Memstore Flush Queue的size不能持续增长),推测为hlog.blocksize*hbase.regionserver.maxlogs触发了memstore flush。然而我们一般都希望时通过前者触发memstore flush而非后者,因为通过WAL触发memstore flush可能会一次flush很多region,造成flush风暴。

    因此blocksize (128 mb) * hbase.regionserver.maxlogs大小需要略大于 hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE,以保证不会提前发生flush。

    目前生产上blocksize为128M,hbase.regionserver.maxlogs为32个,128*32=4096,hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE=0.4*32g*1024=13107,

    blocksize* hbase.regionserver.maxlogs < hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE,因此需要修改hbase.regionserver.maxlogs为103。(13107/128=102)

    相关文章

      网友评论

          本文标题:HBase性能调优之参数探究(一)

          本文链接:https://www.haomeiwen.com/subject/snkerqtx.html