HBase 生产集群性能调优之路

• 另一篇: SPARK 集群生产性能调优之路

• 参考 1: 使用 Prometheus(jmx_exporter) + Grafana 之监控 HBase

  其实本身 hdfs 和 hbase 已内置标准 jmx 指标，例如访问 hbase jmx 指标: http://emr-header-1:16010/jmx，返回的是 json，这里使用 jmx_exporter 的作用只是将 jmx 指标转换为 prometheus 的格式。

1. HBase 中 JVM 配置

在JVM中，默认情况下会设置minimum heap size 为 1/64 可用物理内存，并为maximum heap size设置 1/4 的物理可用内存（不过在Java8 之前，默认最大是1g）。当然，我们可以通过手动指定 JVM 参数，配置JVM的内存，例如：-Xms10g -Xmx10g 在HBase 中，也可以在 hbase-env.sh 中显示指定堆内存大小，例如：

The maximum amount of heap to use. Default is left to JVM default.
export HBASE_HEAPSIZE=1G

这里有个问题是：是否要同时设置-Xms 与 -Xmx为一相同的值？若是将他们设置为同一一个固定值，则它们的优缺点有：

• 对于一些垃圾回收的算法，例如G1，将它们锁定为同一值会更好
  不设置 -Xms可以让VM启动更快，但是接下来，需要在每轮gc 增长堆内存后，才会达到一个稳定状态。这样会导致在启动后，最开始会带来一些延迟，这个延时并不是我们在HBase中期望看到的，因为HBase提供的服务一般都是交互式服务，若是设置-Xms与-Xmx为同一值，则JVM在启动时会稍慢，不过在正常启动后，不会再有隐含的内存大小调整的情况，所以会更稳定。而在RegionServer 的进程中，我们可以在分配工作给它前，稍等一会而，以缓解启动进程的消耗。

• 对于HMaster进程，一般不需要太大内存，2GB 到 4GB就可以满足master的工作需求，因为它的对象分配与销毁的频率远小于RegionServer。

• 对于RegionServer 进程，若是物理机内存为64GB，则一开始可以给它分配10GB的-Xmx，之后可以根据监控（如jstat等）再进行向上调整。不过若是分配了较大的堆内存，我们也必须要考虑不同的GC算法，以支持更大堆内存中的垃圾回收。

• 基于以上场景，我们可以在hbase-env.sh 中配置以下参数：

# Set environment variables here.
export HBASE_MASTER_OPTS="-Xms2g -Xmx2g"
export HBASE_REGIONSERVER_OPTS="-Xms10g -Xmx10g"

如前文所述，不指定-Xms的话，堆内存需要在增长多次后才能到达最大堆内存，导致在重新分配内存时的不必要开销，所以最好是按上述指定。

• HBase中的堆内存管理

在RegionServer中，主要的任务为：接收并处理读写请求。不过除此之外，RegionServer也需要在内存中维护一些内部信息，例如：对于每个打开的region来说，它们都需要在内存里结构化存储，以处理一些常规操作。

在RegionServer启动后，所分配的JVM堆内存大小就已经指定了，无法再增加。所以对于这部分已有的内存，我们需要谨慎使用，其中最重要的一部分就是：如何调整可供读写操作使用的可用内存。

在HBase 1.0 之前，主要有两个参数需要调整，分别为memstores（对于写）以及block cache（对于读）。剩下的内存被用于所有其他杂项使用（例如Java用于存储打开的region的结构）。对于memstore，我们有以下两个参数可以指定：

hbase.regionserver.global.memstore.upperLimit 默认为0.4（40%），也就是memstore可以使用的最大堆内存，
hbase.regionserver.global.memstore.lowerLimit 默认为0.35（30%），也就是memstore可以使用的最小堆内存，
upperLimit 在这里较为重要，因为它指定了对于写操作，可以使用的最大内存。对于读来说，仅有一个参数可供调整：

hfile.block.cache.size 默认为0.4（40%），堆内存中用于分配给block cache的比率
memestore 的 upperLimit ，与 blockcache 的大小，它们的和不能超过80% 堆内存总大小，因为仍需要提供剩余的20% 内存以上，用于regionserver进程完成它自身的部分工作（并且防止Java OOM的问题）。

在HBase 1.0 之后，提供了更多的配置项，用于指定memstore 与 block cache 的upper limit 与 lower limit，例如：

hbase.regionserver.global.memstore.size.min.range 默认未设置，为所有memstore的最小分配内存
hbase.regionserver.global.memstore.size.max.range 默认未设置，为所有memsotre的最大分配内存
hbase.regionserver.global.memstore.size 默认为0.4（40%），也就是memstore默认被分配的对内存比例

hfile.block.cache.size.min.range 默认未设置，为block cache 大小的最小值
hfile.block.cache.size.max.range 默认未设置，为block cache 大小的最大值
hfile.block.cache.size 默认为0.4（40%），也就是堆内存中默认分配给block cache 的比例

hbase.regionserver.heapmemory.tuner.period 默认为60000（60s），定义heap tunner 运行的频率
对于memstore与block cache 的上限与下限，我们必须做配置，除非禁止tuner。

HBase 提供了一个机制是：根据请求流量大小，对堆内存进行动态调整。这就是为什么在开启tuner的情况下，我们必须要设置一个上限与下限。

不过这里仍需要保证的一点是：memstore 与 block cache 的最大使用量不能超过JVM内存的 80%。如果超过了这个比例，则tuner会报错，region server 会退出。这个限制的原因与之前的一样：需要剩余足够的内存供给 region server 进程正常工作。

下图是固定内存与动态内存的一个示例图：

动态内存对应的配置为：

<property>
  <name>hbase.regionserver.global.memstore.size.min.range</name>
  <value>0.2</value>
</property>
<property>
  <name>hbase.regionserver.global.memstore.size.max.range</name>
  <value>0.6</value>
</property>
<property>
  <name>hfile.block.cache.size.min.range</name>
  <value>0.2</value>
</property>
<property>
  <name>hfile.block.cache.size.max.range</name>
  <value>0.6</value>
</property>

它们的初始值为默认的40%内存。Tuner可以在某一个内存（如memstore的内存）达到最小20%后，给另一个分配60%的内存。

Tuner的机制仅是增加某一区域（如memstore）的内存，在增加后另一区域（如block cache）的内存即会减少。基于的是（或是说触发的条件是）：由于内存压力导致的memstore 强制刷新（会要求更多内存，即增加此区域内存），或是内存压力导致的block cache 中的cache 置换。

• 两个主要GC算法，在 HBase 中，主要使用的GC算法为CMS或G1，它们的对比如下：

JVM GC	说明
-XX:+UseSerialGC	串行回收器，适用嵌入式小进程低并发，这个参数会使新生代和老年代都使用串行回收器，新生代使用复制算法，老年代使用标记-整理算法。Serial收集器是最基本、历史最悠久的收集器，它是一个单线程收集器。一旦回收器开始运行时，整个系统都要停止。Client模式下默认开启，其他模式默认关闭。
-XX:+UseParNewGC	ParNew收集器是Serial收集器的多线程版本，Parallel是并行的意思，ParNew收集器是Serial收集器的多线程版本，使用这个参数后会在新生代进行并行回收，老年代仍旧使用串行回收。新生代S区任然使用复制算法。操作系统是多核CPU上效果明显，单核CPU建议使用串行回收器。打印GC详情时ParNew标识着使用了ParNewGC回收器。默认关闭。
-XX:+UseParallelGC	代表新生代使用Parallel收集器，老年代使用串行收集器。Parallel Scavenge收集器在各个方面都很类似ParNew收集器，它的目的是达到一个可以控制的吞吐量。吞吐量为CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机运行100分钟，垃圾收集花费1分钟，那吞吐量就99%。Server模式默认开启，其他模式，默认关闭。Parallel Scavenge提供了两个参数用于控制吞吐量，-XX:MaxGCPauseMillis 参数用于设置最大停顿时间，它的参数运行值是一个大于0的毫秒数，收集器将尽力保证垃圾回收时间不超过设定值，系统运行的需要回收的垃圾总量是固定的，缩短停顿时间的同时会增大回收频度。-XX:GCTimeRatio 参数用户控制垃圾回收时间占比，它运行的参数值是0-100的整数，如果参数设置为19，代表最大GC时间占总时间的5%（1/(1+19)）。Parallel收集器还提供了自适应的调节策略 -XX:UseAdaptiveSizePolicy 即JVM会根据实际运行情况动态调整新生代大小、新生代和s区比例、晋升老年代对象大小等细节参数
-XX:+UseParallelOldGC	新生代和老年代都使用并行收集器。打印出的GC会带PSYoungGen、ParOldGen关键字
-XX:+UseConcMarkSweepGC	低延时（堆内存 < 32GB，Concurrent Mark Sweep 并发标记清除，即使用CMS收集器。它是和应用程序线程一起执行，相对于Stop The World来说虚拟机停顿时间较少。停顿减少，吞吐量会降低。它使用的是 标记清除算法，运作过程为四个步骤，分别是 初始标记—并发标识—重新标记—并发清除。它是老年代的收集算法，新生代使用ParNew收集算法。默认关闭。CMS收集器的缺点是对服务器CPU资源较为敏感，在并发标记时会降低吞吐量。它使用的标记清除算法也会产生大量空间碎片，空间碎片的存在会加大Full GC的频率，虽然老年代还有足够的内存，但是因为内存空间连续，不得不进行Full GC。）
-XX:+UseG1GC	适用高并发低延时，号称通过 region 解决了内存碎片问题，但实际上并无完全解决，设计哲学是想要多快就多快，大不了只回收1%也不影响业务线程，see: https://www.oracle.com/cn/technical-resources/articles/java/g1gc.html
-XX:+UseZGC	适用高并发低延时（要求 Heap Memory >= 32GB），see:https://wiki.openjdk.java.net/display/zgc/Main#Main-EnablingZGC

CMS为较早使用的GC 算法，它可以有效提升HBase的性能，特别是I/O请求的延时。不过它的缺点是：有最大内存的限制。

在CMS刚开始被提出的时候，它可以良好适应当时的服务器硬件性能，不过随着现在超出1TB的内存机器越来越常见，32GB大小的堆内存配置也越来越常见。CMS不适用于较大堆内存的原因是因为：在较大的堆内存中，垃圾回收会造成较长时间的停顿（几秒到十几秒），并最终会导致请求的高延时。

• JVM stop world log

在HBase region server 进程启动后，会启动一个轻量级的线程，定期（500ms）被唤醒，并比较它在唤醒前它睡眠的时间以及实际经过的时间是否一致。如果检测到它实际睡眠的时间超过了500ms，则在服务器日志记录，例如：

2018-08-05 07:11:32,390 INFO  [JvmPauseMonitor] util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 7448ms
GC pool 'ParNew' had collection(s): count=1 time=49ms
GC pool 'ConcurrentMarkSweep' had collection(s): count=1 time=7700ms
...
2018-08-11 23:01:56,686 WARN  [JvmPauseMonitor] util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 3594293ms No GCs detected

第一条是由 gc 导致，记录的是 CMS 消耗了超过7秒等待垃圾回收完成。第二条与机器的暂停无关。根据暂停的时间，日志会以INFO或是WARN级别记录下来，对应的参数如下：

jvm.pause.info-threshold.ms：默认为1000ms（1s），若是停顿时间超过此值，则以INFO级别记录日志
jvm.pause.warn-threshold.ms：默认为10000ms（10s），若是停顿时间超过此值，则以WARN级别记录日志

在做调优时要注意这些日志条目，以了解停顿的频率与时间。并根据时间调整相关timeout配置（例如zookeeper的配置，如果regionserver 超过一段时间未响应，可能会被zookeeper认为宕机）。

据生产真实经历，使用的阿里云 EMR，频繁出现 HRegionServer 挂掉被自动重启，当时工单联系运维工程师他们基本分析是因为数据量过大 (当时确实增加了部分iot设备上行数据)，由于客户投诉十万火急，快速解决方法就是增大 HR 的 -Xms4096m -Xmx4096m -Xmn256m 翻倍或者半倍，然后重启监控观察，当时的环境最终 HR 宕机频率立马就低了很多，生产环境紧急情况可参考，但终究还是得个方位优化才行。

• CMS 与 G1

再回到GC部分，G1的提出就是为了解决：CMS在较大堆内存回收垃圾时产生的长时间停顿问题。下图是两者的实现与对比：

在G1 中，相对于CMS预先配置的堆内存容量，它将整个堆内存空间划分为多个相同大小的regions，一般是2000个左右。在划分好后，G1可以让其中的部分region分别执行Young Generation、Old Generation、以及survivor的角色。G1 gc采用的策略就是在这些区域中执行较多的gc任务，以尽可能地减少jvm pause以及对用户的影响。虽然这些额外的工作是会对延时有较大的影响，不过从长远来看，它的jvm pause时间会更短，并可以提供更稳健的延时，而不是抖动的延时。

• CMS

CMS是一个性能较好的GC算法，已被使用多年。启用的参数为：-XX:+UseParNewGC -XX:+UseConcMarkSweepGC

（这里其实在指定 -XX:+UseConcMarkSweepGC 后就默认已经指定了-XX:+UseParNewGC，这里显示指定为了之后进一步的讨论）

第一个选项是为Young Generation 设置使用Parallel New Collector：它在清理Young Generation 时会停止整个Java 进程。这个在Young Generation中是可以被接受的，因为它的内存相对Old Generation 会少得多，所以此过程也不会消耗太多的时间，一般少于几百毫秒。不过，这个设置对于Old Generation是不合适的，在最坏的情况下，可能会导致多达几秒的延时。

对此，CMS可以较好地解决此问题，它会尽可能地并行做gc，而不停止Java 进程。虽然此方法会造成额外的CPU资源消耗，但是可以减少或是避免JVM pause。CMS也是hbase 中默认的gc算法。

在CMS中，我们可以做的第一个调整是：Young Generation的大小。它默认的值较小，在region server 执行写操作时，会将数据写入memstore，过小的Young Generation会让这部分数据停留在此区域的时间较短，并可能造成不必要的generation 提升（Young Generation 提升到 Old Generation）。对此，可以将Young Generation的大小设置为一个固定的、更大的一个值，以减少此类影响，例如：

-XX:MaxNewSize=128m -XX:NewSize=128m

或者也可以直接用这两个配置的简写：-Xmn128m。

128MB是一个较好的起点，之后可以根据JVM的指标，确定是否满足需求或是是否需要添加更多的内存。不过对于有较高负载的region server 来说，默认的Young Generation 的大小有些过于小了。如果在一开始不调整此参数的话，我们可能会注意到CPU的使用率会偶尔突然增高，因为JVM需要花时间将Young Generation 中的对象提升到Old Generation中（由于Young Generation中内存不足）。

CMS还有一个参数用于控制：什么时候开始做concurrent mark and sweep 检查。这个参数可以通过以下配置设置：

-XX:CMSInitiatingOccupancyFraction=85

此参数指定的是：什么时候启动后台cms垃圾回收。此参数不能配置过高，为了避免concurrent mode failure 问题。此问题发生的场景为：在后台mark and sweep 工作正在进行时，堆内存已经耗尽了所有的可用空间。则此时，JRE必须停止Java 进程，并且通过清除垃圾，或是将Young Generation 中的对象移动到 Old Generation中（如果这些对象已经够old），以释放空间。

设置此值为85%，表示在堆内存耗尽之前就会开始执行concurrent collection 的工作，但也不会是太早去做这个工作。一个常规的建议是：将这部分值设置为稍高于memstore与block cache总和大小的值。它们的总和一般为80%（memstore 40%，block cache 40%），所以我们会优先设置为85%左右或以上。

下面是一个起始的CMS参考配置：

export HBASE_REGIONSERVER_OPTS="-Xms10g -Xmx10g -Xmn128m \ -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=85 \ -XX:+UseCMSInitiatingOccupancyOnly"

• G1

G1的启用方法为：-XX:+UseG1GC

除此之外，还需要设置一个预期最大的gc pause 时间。不过这个仅是一个soft goal，JVM会尽量满足此目标。不过若是为了满足工作负载，此暂停时间可能会更长。此参数为：-XX:MaxGCPauseMillis=200

默认即为200ms，可以根据需求做进一步调整。最后一个参数需要调整的是：什么时候gc collector 开始一个concurrent GC cycle，以整个堆内存已使用部分百分比为阈值，默认为45%，例如：-XX:InitiatingHeapOccupancyPercent=45

可以先以此为初始配置，然后再根据负载调整G1 中每个region的大小等，此部分需要更深入的G1 算法知识，之后再详述。

另一个可以用于参考的配置是 HubSpot 发布的一个一篇 HBase 中 G1 GC 调优文档：https://product.hubspot.com/blog/g1gc-tuning-your-hbase-cluster，根据文档中的建议，我们可以尝试使用以下配置：

-XX:MaxGCPauseMillis=50
-XX:+UnlockExperimentalVMOptions
-XX:-OmitStackTraceInFastThrow
-XX:+ParallelRefProcEnabled
-XX:+PerfDisableSharedMem
-XX:-ResizePLAB
-XX:ParallelGCThreads=8 + (<no. of logical processors> - 8) * (5/8)

另一方面，根据另一篇 Intel 团队文档：https://software.intel.com/en-us/blogs/2014/06/18/part-1-tuning-java-garbage-collection-for-hbase
对 Young Generation 的调优的建议为（默认 Young Generation 的比例为 5%）：

32GB heap, -XX:G1NewSizePercent=3;
64GB heap, -XX:G1NewSizePercent=2;
100GB and above heap, -XX:G1NewSizePercent=1;

最终 Intel 给出的 region server JVM 的参数为：

-XX:+UseG1GC
-Xms100g -Xmx100g # (Heap size used in our tests)
-XX:MaxGCPauseMillis=100 # (Desired GC pause time in tests)
-XX:+ParallelRefProcEnabled
-XX:-ResizePLAB
-XX:ParallelGCThreads= 8+(40-8)(5/8)=28
-XX:G1NewSizePercent=1

针对这里的建议是：对 Young Generation，使用 Intel 的配置；对 RegionServer 其他的配置，采用 HubSpot 的配置（为2016年发布，Intel 对 RegionServer 的配置建议为 2014 年发布）。

参考资料

• 参考1 Thanks to the author, reprinted from: https://www.cnblogs.com/zackstang/p/11573719.html

• 参考2: 全面认识HBase架构

• 参考3: HBase 生产集群间歇性停顿 10s 分析调优