Hbase集群运维及应用性能优化总结（hbase1.20+）

（一）. 操作系统 

     

      1. 足够大的内存

      2. 操作系统64位，jdk64位

      3. 设置linux swap空间的swappiness=0

   

          a1. 永久有效设置（需系统重启） sudo vim /etc/sysctl.conf 在这个文档的最后加上这样一行:

　　             vm.swappiness=0

          a2. 临时修改  sudo sysctl vm.swappiness=0

    

      4. CPU

      

          Make sure you have set up your Hadoop to use native, hardware checksumming. See link:[hadoop.native.lib]

        

(二). 网络

    

    1. 考虑数据传输,带宽足够大(因为主要和datanode节点之间做数据传输)

(三). Java

    1. GC优化

      

       a. CMS failure modes问题 

       

          尽可能早的启动CMS, -XX:CMSInitiatingOccupancyFraction=60~70 (备注：阈值越低，gc频繁，cpu使用率高)

          

       b. old generation heap fragmentation brought问题(备注：因Region flush导致的内存碎片问题造成小内存块无法使用，从而引起fullgc时间过长超过regionserver向hmaster心跳时间，最终导致regionserver误判为挂掉)

          

          hbase.hregion.memstore.mslab.enabled=true // 开启MSLAB (备注: 内存小或单个server上region数少的情况下，可关闭)

          hbase.hregion.memstore.mslab.chunksize=2m // chunk的大小，越大内存连续性越好，但内存平均利用率会降低

          hbase.hregion.memstore.mslab.max.allocation=256K // 通过MSLAB分配的对象不能超过256K，否则直接在Heap上分配，256K够大了

          

          写负载高场景--降低YGC的开销---两种调整参数方式:

          A). hbase.hregion.memstore.chunkpool.maxsize=0.5 (备注: ; 0为禁用: 作用: 降低YGC的开销，reuse chunk; 赋值区间为global memstore size的百分比0-1之间 )

          B). -XX:PretenureSizeThreshold=？（备注： 作用：有对象的size超过该值，直接在老年代分配内存，避免大对象在s0-s1之间copy; 值设置略小于hbase.hregion.memstore.mslab.chunksize的值即可）

      c. enabling the off-heap Block Cache

         

          A). LruBlockCache （备注：全部使用的是Java heap； 默认）

          B). BucketCache (备注: 尽量缓存数据在 off-heap)

          

(四). Hbase配置调整(根据监控或压测情况，谨慎调整)

    1.

    

    2. (hdfs-default.xml) dfs.datanode.failed.volumes.tolerated(备注：datanode可以忍受的磁盘损坏的个数) 

    

    3. hbase.regionserver.handler.count(regionServer 处理客户端请求的线程数)

    

    4. hfile.block.cache.size(备注： RegionServer 内存读)

    

    5. Prefetch Option for Blockcache (备注： 快速读)

    

    6. hbase.regionserver.global.memstore.size(设置过小，会造成RS响应迟钝或频繁的compaction)

    

    7. hbase.regionserver.global.memstore.size.lower.limit

    

    8. hbase.hstore.blockingStoreFiles

    

    9. hbase.hregion.memstore.block.multiplier

    

    10. hbase.regionserver.checksum.verify (启用hbase的checksum，替代hdfs的)

    

    11. Tuning callQueue Options(备注: 至少有一个写队列)

         

        A). hbase.ipc.server.num.callqueue > 1 

        B). hbase.ipc.server.callqueue.read.ratio(0-1之间)

        C). hbase.ipc.server.callqueue.scan.ratio(0-1之间;;; 备注: determine the ratio of read queues used for Gets and Scans; 至少有一个get队列)

        D). hbase.ipc.server.callqueue.handler.factor (备注： 0为所有的handler共用一个queue； 1为一个handler一个queue; 0-1之间，比如0.5为两个handler共享一个queue;;; 影响：一个handler只处理他负责的queue，如果配置一个handler一个queue，则有长时间运行task的队列，不能有已经空闲的handler来帮忙处理，只能负责他的handler独自苦逼处理)     

        

    12. ZooKeeper (保证有一个专用的磁盘，具体看zooKeeper配置)

    

    13. Schema Design

       

        A). 列簇数决策（hbase官方说明一个列簇可以避免写多读少的场景下，多个列簇，在flush和compaction以region为单位的情况下，单个columnFamily达到数据量上限，造成所有columnFamily都被flush，从而引起频繁的compaction，造成IO浪费；如果某些列被经常查询，在读多写少的场景下，把这些列单独建立一个列簇，提高访问性能）

        B). rowkey(设计尽可能短和保证查询效率),列簇名和列名尽可能短

        C). region个数决策(备注: region数越少，集群运行越流畅； 一般20-200个比较合理)，最好建表的时候，Pre-splitting

            1). region个数计算公式（HBase 0.98.x）: ((RS Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (# column families))

        D). 手动管理split和compaction，根据业务忙闲来灵活调整，避免自动管理，影响业务

        E).