网易视频云：HBase GC的前生今世 – 演进篇( 二 ) _内存

文章插图
官方针对该优化也进行了简单的测试，使用jstat -对优化前后的JVM GC情况进行了统计，具体的测试条件和测试结果如下所示：

文章插图
很显然，经过优化后YGC时间降低了40+％左右，FGC的次数以及时间更是大幅下降。
对于需要深入了解HBase针对所做的GC优化的朋友，强烈建议首先阅读之前的3篇系列博文：part1 , part2 和part3 。文中重点介绍了的两种实现方案：和。优化－方案
其中是目前HBase的默认方案，这种方案会将内存区分为3个部分：-区、mutil-区以及in-区，一个Block块从HDFS中加载出来之后首先放入区，后续如果有多次请求访问到这块数据的话，就会将这块数据移到mutil-区。随着Block数据从-区晋升到mutil-区，基本就伴随着对应的内存对象从young区到old区，晋升到old区的Block被淘汰后会变为内存垃圾，最终由CMS回收掉，CMS回收之后必然会产生大量的内存碎片，碎片空间一直累计就会产生臭名昭著的Full GC 。
为了减少频繁CMS GC 产生的碎片问题，社区采纳了阿里开发者的新方案：。这种方案还是采用“将小碎片整理为大碎片”的思路，由程序在初始化的时候就申请了很多大小为2M的，数据Block的Get/Cache动作只是对这片空间的访问/覆写，CMS碎片会自然大大降低。有三种工作模式：heap、以及file，其中heap模式表示将数据存储在JVM堆内存，模式表示将数据Block存储到操作系统内存，file模式表示将数据Block存储到类似于SSD的外部高速缓存上；很显然，模式和file模式根本没有将数据Block存在JVM堆内存，所以几乎不会出现Full GC，而heap模式即使数据存储在JVM堆内存，也会因为内存由程序独立管理大大降低内存碎片。
【网易视频云：HBase GC的前生今世 – 演进篇】针对的两种实现方案，分别简单地对内存碎片产生情况和GC情况进行了统计，结果如下：

文章插图
从结果可以看出，大大减少了碎片的产生，而且YGC和FGC时间也极大地得到了改善。需要注意的是，此结论是在部分缓存未命中的情况下得出的，缓存全部命中的场景结果会有所不同。
总结
所有构建在JVM上的应用或多或少都会受到GC的影响，尤其对于大内存系统更是如此，HBase也不例外。针对GC问题，一方面我们期待JVM能够做出更多地改进和优化，另一方面，我们也可以从内存管理方面进行更多地探索，不断优化内存的使用。HBase在0.98之后的版本还不断针对GC进行着优化，后续再进行补充！