日期:2014-05-16  浏览次数:20545 次

hbase优化相关参数说明

1、hbase.regionserver.handler.count 

RegionServers处理远程请求的线程数,如果注重TPS,可以调大,默认10
        note1:值设得越大,意味着内存开销变大,hbase.client.write.buffer * hbase.regionserver.handler.count,hbase.client.write.buffer默认大小为2M
        note2:  对于提高write的速度,如果瓶颈在做flush、compact、split的速度,磁盘io跟不上,提高线程数,意义不大。

2、hfile.block.cache.size

        默认0.25,hfile/StoreFile的最大读缓存空间,所占堆空间比例。
        note1:参数设定根据应用场景,如果读比写多,建议调大,读写平衡,建议设成0.3,如果读少于写,建议调小
        note2:block.cache.size memstore limits 这些内存加起来不要超过60%。因为剩余的内存还要用来做其他事情。否则容易OOM

3、hbase.regionserver.global.memstore.upperLimit

    默认0.4,memstores所占最大堆空间比例,如果达到上限,阻塞更新,强制flush数据

4、hbase.regionserver.global.memstore.lowerLimit

    默认0.35,menstores达到上限,做flush,知道memstores降到该值,停止flush。

5、hbase.hstore.blockingStoreFiles

    默认7,如果一个hstore里面storefile超过这个数字(每次memstore做flush时会生成一个hstore),会阻塞相应hregion的更新,知道一个compact压缩过程结束,或者阻塞时间超过hbase.hstore.blockingWaitTime(默认90s)
    note1:hbase.hstore.compactionThreshold,默认3,如果一个hstore里面的storefile数量超过这个数字,一个压缩任务会启动,将所有的storefile合并成一个。如果数量较多,那么会推迟合并过程,但是再执行时,将会消耗更多时间。
    note2:对于持续写的系统,这个参数的设置,是为了compact与flush的速度平衡,如果compact的速度远小于flush的速度,有可能造成 文件io过多,造成too many openfile异常,以及给namenode带来更大的压力。

6、hbase.hregion.memstore.flush.size、hbase.hregion.memstore.block.multiplier

   默认134217728、2
   第一个参数:如果一个memstore大小超过flushsize,则启动flush。后台会有一个线程在周期hbase.server.thread.wakefrequency内,定时检查