Hbase-之操作性能优化配置-RPC优化

Hbase-之操作性能优化配置-RPC优化

1 调整Hbase server的RPC处理能力

这里的server主要指的是regionserver，因为毕竟Hbase实际搞事情的还是regionserver，我们可以在hbase-site.xml中配置

• 主要取决你集群中regionserver中的核数，x可以配置hbase.regionserver.handler.count = x

• 可选的配置，按照不同的服务将读、写请求队列分别划分成不同的请求队列，参数为hbase.ipc.server.callqueue.handler.factor

  • 0意味着使用单独的1个队列处理read、write请求；
  • 1意味着每个handler一个请求队列，资源足够；
  • 0~1之间的值，如 .5意味着1/0.5=2，相当于2个handler共享一个队列；

• hbase.ipc.server.callqueue.read.ratio或者hbase.ipc.server.callqueue.read.share (Hbase-0.98),调整读写队列的占比；

  • 0.5代表read、write拥有同样的请求处理队列数量；
  • <0.5代表read数量比write数量多；
  • >0.5代表write数量比read数量多；

• hbase.ipc.server.callqueue.scan.ratio(Hbase 1.0+)，将读取请求队列分成小的读取队列和大的读取队列；

  • 0.5 means that there will be the same number of short-read and long-read queues；
  • < 0.5 for more short-read
  • > 0.5 for more long-read

2 为RPC禁用Nagle算法

因为延迟的ACK会使RPC的往返时间增加约200ms，所以需要禁用，我们要设置如下参数。

• 在Hadoop中core-site.xml：
  • ipc.server.tcpnodelay = true
  • ipc.client.tcpnodelay = true
• 在HBase的hbase-site.xml：
  • hbase.ipc.client.tcpnodelay = true
  • hbase.ipc.server.tcpnodelay = true

3 限制服务端故障影响，zookeeper故障发现报告

• 在hbase-site.xml：
  • 将设置zookeeper.session.timeout为30秒或更短以进行绑定故障检测（20-30秒是一个好的选择），便于更快的发现并且报告故障；
  • 注意：sessionTimeout在Zookeeper的时间限制为2次～20次之间，tickTime（ZooKeeper使用的基本时间单位为ms，默认值为2000ms，但是用于执行心跳，最小会话超时timeout将是tickTime的两倍）。
• 检测并避免HDFS DataNode运行不正常或发生故障：在hdfs-site.xml和中hbase-site.xml，设置以下参数：
  • dfs.namenode.avoid.read.stale.datanode = true
  • dfs.namenode.avoid.write.stale.datanode = true

4 在Hbase服务端进行延迟优化

该优化主要是避免网络传输数据块，尽量从RegionServer本地的节点读取本地数据块，我们需要在DataNode与dfsclient(Regionserver)端都加载hadoop本机.so库,在配置完Hadoop之后，将dfs.client.read.shortcircuit设置为true，并将dfs.domain.socket.path路径配置为datanode和dfsclient共享并重新启动，然后配置regionserver / dfsclient端。

按照以下的配置按照先后顺序进行配置。

• 修改hbase-site.xml：

  • dfs.client.read.shortcircuit = true
  • dfs.client.read.shortcircuit.skip.checksum = true so we don’t double checksum (HBase does its own checksumming to save on i/os. See hbase.regionserver.checksum.verify for more on this.
  • dfs.domain.socket.path 去匹配hadoop中对datanode设置的值；
  • dfs.client.read.shortcircuit.buffer.size = 131072 对于避免OOM error非常重要 ，假如没有设置，那么会使用Hbase的默认配置hbase.dfs.client.read.shortcircuit.buffer.size; 它的默认值也是131072.

• 确保数据本地化，修改hbase-site.xml：

  • set hbase.hstore.min.locality.to.skip.major.compact = 0.7 (Meaning that 0.7 <= n <= 1)

• 确保DataNode有足够的handler处理器来处理块传输，修改hdfs-site.xml：

  • dfs.datanode.max.xcievers >= 8192
  • dfs.datanode.handler.count = nums of cores

重启Hbase之后，查看日志，如果缺少相关配置，那么只能看到无用的抱怨日志信息，而短路读取数据只会在后台安静的运行，它没有提供相关的度量，所以无法正确通过正确手段确定该有效性；但是读取延迟应该以日志形式展示出来，尤其是数据集大小超过可用缓存大小的时候，应该让用户能够感知。

有关短路读取的更多信息，请参阅Colin推出的旧博客， 《改进的短路本地读取如何为Hadoop带来更好的性能和安全性》。在HDFS-347的问题显示需要注意的几点意见。

你可能会使用到几个高级配置：

dfs.client.read.shortcircuit.streams.cache.size和 dfs.client.socketcache.capacity,这些选项的文档很少，你可以选择读取源代码。

5 JVM调整

• 可以选择使用CMS收集器：-XX:+UseConcMarkSweepGC

# 通过以下方式进行JVM参数的传入，放在hbase shell的前面
HBASE_SHELL_OPTS="-verbose:gc -XX:+UseConcMarkSweepGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps \
  -XX:+PrintGCDetails -Xloggc:$HBASE_HOME/logs/gc-hbase.log" ./bin/hbase shell

• 保证伊甸园eden区的空间尽可能的小去减少平均收集时间

-XX:CMSInitiatingOccupancyFraction=70

• 针对低GC延迟时间，但是牺牲吞吐量

-Xmn512m

• 开启并行GC伊甸园区

-XX:+UseParNewGC

• 避免在集群压力大的情况下收集

-XX:+UseCMSInitiatingOccupancyOnly

• 限制每次扫描请求返回的结果大小，导正所有的数据都能正常进入survivor区域，但是不限时间，修改***hbase-site.xml***

hbase.client.scanner.max.result.size = 1/8 of eden space 
# 假如-Xmn512m ，那么这个值就设置成51MB
51*8 = 410 
410 / 512 = 80%
这是默认的伊甸园区的占比

• 将max.result.size * handle.count的值< 幸存者区域的大小

6 操作系统级别的调整

• 关闭下面的选项

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

• 设置vm.swappiness = 0
• 设置vm.min_free_kbytes最少为1GB，如果系统内存很大，可以设置8GB
• disable NUMA zone reclaim通过vm.zone_reclaim_mode = 0

7 特殊的案例调整

• 对于很快就提示失败的应用，用以下配置代替等待wating,修改***hbase-site.xml***
  • Set hbase.client.pause = 1000
  • Set hbase.client.retries.number = 3
  • If you want to ride over splits and region moves, increase hbase.client.retries.number substantially (>= 20)
  • Set the RecoverableZookeeper retry count: zookeeper.recovery.retry = 1 (no retry)
  • 在服务端的***hbase-site.xml***，修改ZK发现服务失败的超时时间为20～30s这样很棒， zookeeper.session.timeout = 30

其它特殊情况可以参照官网：https://hbase.apache.org/2.2/book.html#_special_cases