HBase Memstore专属JVM策略MSLAB机制深入剖析-OLAP商业环境实战

本文主要是介绍HBase Memstore专属JVM策略MSLAB机制深入剖析-OLAP商业环境实战，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本套技术专栏是作者（秦凯新）平时工作的总结和升华，通过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。期待加入IOT时代最具战斗力的团队。QQ邮箱地址：1120746959@qq.com，如有任何学术交流，可随时联系。

1 垃圾回收器组合（内存碎片）

垃圾回收器从线程运行情况分类有三种

串行回收，Serial回收器，单线程回收，全程stw；
并行回收，名称以Parallel开头的回收器，多线程回收，全程stw；
并发回收，cms与G1，多线程分阶段回收，只有某阶段会stw；
cms只会回收老年代和永久带（1.8开始为元数据区，需要设置CMSClassUnloadingEnabled），不会收集年轻带；
cms是一种预处理垃圾回收器，它不能等到old内存用尽时回收，需要在内存用尽前，完成回收操作，否则会导致并发回收失败；所以cms垃圾回收器开始执行回收操作，有一个触发阈值，默认是老年代或永久带达到92%；

垃圾回收的四个主要阶段：

初始标记
初识标记：这个过程是标记从gc root出发发的直接相关的引用。这个时间很短，但是是stop the world;
并发标记
并发标记：用户线程并行执行，进行相关的引用标记。这个时间很长，一般决定于堆内存的大小。所使用的线程数为(cpu个数+3)/4，所以当cpu核数很少时，在并发标记阶段会出现严重的性能下降。为了解决这个问题，对于cpu核数很少时，在并发标记阶段会与用户线程交叉执行，以使服务器性能不至于下降的太严重。但是这样操作会使标记过程所耗费的时间更长。
重新标记
重新标记：因为在并发标记时，用户线程在执行，可能会造成再次的实例引用。所以需要重新标记一下。这个阶段的标记也是stop the world,并且是并行标记。
并发清除
并发清除，即清除相关的垃圾。

CMS的缺点：

由于CMS使用的是标记清除算法，会造成内存碎片，当老年代无法再次分配内存时需要FULL GC。CMS提供了一个参数-XX+UseCMSCompactAtFullCollection，即在执行FULL GC时开启内存碎片的合并整理过程。这也会引起stop the world。
CMS在进行垃圾回收时，无法处理浮动垃圾。所以在进行垃圾回收时，需要留有一定的内存供用户线程使用。CMS提供了一个内存触发垃圾回收的内存使用比例：
-XX:CMSInitiatingOccupancyFraction，如果预留的内存不够使用，就会出现Cocurrent Mode Failure失败，这时就需要启动后备预案：临时使用串行收集器重新进行老年代的垃圾收回，这个时间更长。
CMS 用来进行老年代的垃圾回收，这个与ParNew（多线程的串行垃圾回收）进行组合，用于整个的堆内存的垃圾回收。

2 FULL GC 在大内存处理的无力感

随着硬件的进步，32GB，64GB甚至100GB的内存已经很多了，基于JVM的CMS垃圾回收已经有种无力感，FULL GC的时间遵循8-10秒/G的压迫。100GB简直就是灾难啊，800-1000秒，可是都接近甚至大于10分钟了啊。
同步模式失败：CMS在没有完全释放老年代的内存空间时，新生代对象要过快转化，导致此时的收集器停止并发收集过程，转化为单线程的暂停，可谓是一触即发Ful GC。
碎片化造成新生代升到老年代的对象比老年代所有可以使用的连续空间都大。比如：老年代有500MB的空间可以使用，但是都是1KB的碎片空间，现在有一个2KB的新生代对象转换为老年代对象，此时因为没有2KB的连续空间，所以不得不FullGC。
MemStore会定期刷写成为一个HFile，在刷写的同时这个Memstore所占用的内存空间就会被标记为待回收，但是因为是按照顺序的，所以会出现以下情况。
此时老年代若都是1KB的碎片空间，现在有一个2KB的新生代对象转换为老年代对象，此时因为没有2KB的连续空间，所以不得不FullGC。
因此朱丽叶暂停就诞生了，危机越来越严重。
基于此，JVM想到了线程解决方案，叫做TLAB(Thread-Local allocation Buffer)，当使用TLAB时，每一个线程都会分配一个固定大小的内存空间，但是缺点就是无论你的线程里面有没有对象，其中有很大一部分空间都是闲置的，内存空间的利用率就会降低。

3 HBase的TLAB的升华MSLAB

因为HBase中多个Region是被一个线程管理的，但是多个MemStore占用的内存还是无法合理的分开，于是Hbase就自己实现了一套以Memstore为最小单元格的内存管理机制，叫做MSLSB（MemStore-Local Allocation Buffers）。这套思路即来自TLAB，只不过内存空间是由MemStore来分配。
MLSB引入chunk的概念，所谓chunk就是一块内存，大小默认为2MB。
RegionServer中维护者一个全局的MemStoreChunkPool实例，从名字上很容易看出，是一个Chunk 池。
每一个MemStore里面都会有一个MemStoreLAB实例。
当MemStore接收到KeyValue数据的时候先从ChunkPool中申请了一个chunk，然后放到MemStoreLAB实例中。
一旦MemStoreLAB实例中放满了，就新申请一个新的。
如果MemStore因为刷写而释放内存，则按chunk来清空内存。
上面的流程就解决了小碎片引起的无法插入大数据的问题，

4 MSLAB的参数设置

  hbase.hregion.memstore.mslab.enabled:设置为true，即打开MSLAB，默认是true。hbase.hregion.memstore.chunkpool.maxsize:表示在整个Memstore可以占用的堆内存的比例。默认值是0，因此设置大于0,才算真正开启MSLAB.hregion.memstore.chunkpool.initialsize:表示在RegionServer启动的时候预分配一些chunk出来。也是一个比例值，该值表示预分配的chunk占用总的chunkpool的大小。hbase.hregion.memstore.mslab.chunksize:每一个chunk的大小，默认是2048*1024，即2MB。hbase.hregion.memstore.mslab.max.allocation:能放入chunk的最大单元格大小，默认是256KB,已经很大了。