【大数据实践】网易杭研HBase集群G1GC节点FGC调优

发布时间:2020-07-07 15:21:26   来源:网络

问题背景

网易杭研作为网易互联网技术底座,提供了HBase在内的大数据技术支持。近期,某业务HBase集群之前使用CMS GC,在某些离线请求量非常大的场景下,会出现长时间的Promotion Failure类型的FGC,导致RegionServer宕机。Promotion Failure类型的FGC发生大多是因为系统长时间运行后产生大量的内存碎片,导致没有完整的一片可用内存。为了防止这种情况发生,尝试使用G1GC代替CMS GC,理论上可以解决Promotion Failure类型的FGC。

问题现象

改成G1GC后,业务线上HBase集群一个分组的RegionServer发生了FGC,导致节点宕机,服务受到一定影响。网易杭研大数据团队查看了对应的GC日志,如下图所示:


问题分析

分析日志,网易杭研大数据团队基本上确认JVM在GC的时候依然不断地进来数据,导致内存无法分配,最终导致Full GC。这里面有两个原因,其中之一是MixGC触发的时机不对,本实例设置的最大内存为40g,InitiatingHeapOccupancyPercent值为65,理论上所占内存达到40g*65%=26g的时候就应该执行MixGC。但实际上JVM执行MixGC的时候内存已经占用到了34g。如下图:


为什么会这样?很简单,JVM就是需要这么多内存,没有多少内存垃圾可以GC出来。怎么确认需要这么多内存呢?看了下Memstore的大小就确认了:


在高峰期光Memstore就需要25G的内存,已经达到了InitiatingHeapOccupancyPercent阈值所规定的的MixGC执行阈值,这还不算读缓存以及预留的10%~20%内存。可见,JVM就是需要36G那么多内存,GC不下去属于正常情况,一旦在GC的时候进来大量数据,就很有可能导致所有内存都被耗尽,最终FGC。

为什么MemStore占用那么多?答案也很简单,这个RegionServer上的region很多,达到了559个,一个region最大占用128M内存,25G内存也是容易达到的。

解决方案

这种FGC如何避免呢?网易杭研大数据团队建议做如下2点优化:

1.内存需要增大,从40g增大到60g

2.留给Memstore的26g不变,这样hbase.regionserver.global.memstore.size需要从0.65调整成0.45

业务实践证明,经过这样的调整后,65%的InitiatingHeapOccupancyPercent可以不用变,基本上可以满足JVM需求,不会发生FGC。

注:G1GC是一个需要根据业务不同,最典型的是Xmx总内存大小需要根据Memstore占用总内存大小的不同进行设置,占用内存越大,设置的总内存大小就越大,防止出现内存不够导致FGC发生。

来源:网易云         作者:范欣欣,网易杭研大数据技术专家