利用Arena Allocation避免HBase触发Full GC

简介:

Arena Allocation,是一种GC优化技术,它可以有效地减少因内存碎片导致的Full GC,从而提高系统的整体性能。本文介绍Arena Allocation的原理及其在Hbase中的应用-MSLAB。

背景

假设有1G内存,我顺序创建了1百万个对象,每个对象大小1K,Heap会被渐渐充满且每个对象以创建顺序相邻。此时,如果我释放50万个奇数对象,即 1 3 5 7后,剩余空间会多出500M,而这段内存空间就不再连续了。问题出现?
如果我打算new一个2K大小的对象,JVM将无从分配它,因为找不到连续可用的内存空间来容纳这个对象,就算Heap当时还有500M的剩余空间,也无能为力。最终,JVM会选择触发Full GC重新压缩内存使之连续,然后再分配。

结论:触发Full GC,并不只有在内存满或达到触发比例的时候,还有可能是因为内存碎片。

产生内存碎片的主要原因是:

  • 分配的大小不一。
  • 分配的空间不连续。
    如何检测因内存碎片触发了Full GC?
    通过启动java时,添加 -XX:PrintFLSStatistics=1 参数来打印每次gc前后的Heap余量。较大的余量,可以怀疑Heap中存在内存碎片过多。
    另外这篇blog有更详细的图文解释:

http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-2/

HBase中的内存碎片

HBase为了提高写入性能,为每个region添加了一个内存写缓存-Memstore。当单个Memstore的大小达到memstore.size或Heap内存达到hbase.regionserver.global.memstore.upperLimit/lowerLimit百分比限制时,就会触发整个region的flush,最终将所有数据写入HDFS并释放region下所有Memstores占用的内存(GC不一定及时)。

Region flush导致内存碎片的示意图:

左边五颜六色的是不同的region在内存中的位置,它是无序的,因为客户端的请求是无规律的。此时假设黄色的region触发了flush,那么右边将会出现与之对应的多个空洞,即内存碎片。这张图以region为粒度,仅仅是为了更直观地表示这种现象。真实场景中,这些空洞是更细粒度的KeyValue级对象,它能直接导致创建对象时触发Full GC。

Arena Allocation

Arena Allocation是一种非传统的内存管理方法。它通过顺序化分配内存,内存数据分块等特性使内存碎片粗化,有效改善了内存碎片导致的Full GC问题。

它的原理:

  • 创建一个大小固定的bytes数组和一个偏移量,默认值为0。
  • 分配对象时,将新对象的data bytes复制到数组中,数组的起始位置是偏移量,复制完成后为偏移量自增data.length的长度,这样做是防止下次复制数据时不会覆盖掉老数据(append)。
  • 当一个数组被充满时,创建一个新的数组。
  • 清理时,只需要释放掉这些数组,即可得到固定的大块连续内存。
    在Arena Allocation方案中,数组的大小影响空间连续性,越大内存连续性越好,但内存平均利用率会降低。

HBase的解决方案-MSLAB

MSLAB,全称是 MemStore-Local Allocation Buffer,是Cloudera在HBase 0.90.1时提交的一个patch里包含的特性。它基于Arena Allocation解决了HBase因Region flush导致的内存碎片问题。

MSLAB的实现原理(对照Arena Allocation,HBase实现细节):

  • MemstoreLAB为Memstore提供Allocator。
  • 创建一个2M(默认)的Chunk数组和一个chunk偏移量,默认值为0。
  • 当Memstore有新的KeyValue被插入时,通过KeyValue.getBuffer()取得data bytes数组。将data复制到Chunk数组起始位置为chunk偏移量处,并增加偏移量=偏移量+data.length。
  • 当一个chunk满了以后,再创建一个chunk。
  • 所有操作lock free,基于CMS原语。
    优势:

  • KeyValue原始数据在minor gc时被销毁。

  • 数据存放在2m大小的chunk中,chunk归属于memstore。
  • flush时,只需要释放多个2m的chunks,chunk未满也强制释放,从而为Heap腾出了多个2M大小的内存区间,减少碎片密集程度。
    开启MSLAB

hbase.hregion.memstore.mslab.enabled=true // 开启MSALB
hbase.hregion.memstore.mslab.chunksize=2m // chunk的大小,越大内存连续性越好,但内存平均利用率会降低
hbase.hregion.memstore.mslab.max.allocation=256K // 通过MSLAB分配的对象不能超过256K,否则直接在Heap上分配,256K够大了

本文来源于"阿里中间件团队播客",原文发表时间" "

相关文章
|
缓存 监控 Java
"Java垃圾回收太耗时?阿里HBase GC优化秘籍大公开,让你的应用性能飙升90%!"
【8月更文挑战第17天】阿里巴巴在HBase实践中成功将Java垃圾回收(GC)时间降低90%。通过选用G1垃圾回收器、精细调整JVM参数(如设置堆大小、目标停顿时间等)、优化代码减少内存分配(如使用对象池和缓存),并利用监控工具分析GC行为,有效缓解了高并发大数据场景下的性能瓶颈,极大提升了系统运行效率。
690 4
|
存储 算法 Java
如何降低90%Java垃圾回收时间?以阿里HBase的GC优化实践为例
GC一直是Java应用中讨论的一个热门话题,尤其在像HBase这样的大型在线存储系统中,大堆下(百GB)的GC停顿延迟产生的在线实时影响,成为内核和应用开发者的一大痛点。 过去的一年里,我们准备在Ali-HBase上突破这个被普遍认知的痛点,为此进行了深度分析及全面创新的工作,获得了一些比较好的效果。
6116 0
|
算法 Java 分布式数据库
如何降低90%Java垃圾回收时间?以阿里HBase的GC优化实践为例
GC一直是Java应用中讨论的一个热门话题,尤其在像HBase这样的大型在线存储系统中,大堆下(百GB)的GC停顿延迟产生的在线实时影响,成为内核和应用开发者的一大痛点。
9855 0
|
Java Hbase
如何降低90%Java垃圾回收时间?以阿里HBase的GC优化实践为例
GC一直是Java应用中讨论的一个热门话题,尤其在像HBase这样的大型在线存储系统中,大堆下(百GB)的GC停顿延迟产生的在线实时影响,成为内核和应用开发者的一大痛点。
10114 0
|
分布式计算 Java Hadoop
java使用hbase、hadoop报错举例
java使用hbase、hadoop报错举例
478 4
|
分布式计算 Ubuntu Hadoop
Ubuntu22.04下搭建Hadoop3.3.6+Hbase2.5.6+Phoenix5.1.3开发环境的指南
呈上,这些步骤如诗如画,但有效且动人。仿佛一个画家在画布上描绘出一幅完美的画面,这就是你的开发环境。接下来,尽情去创造吧,祝编程愉快!
1136 19
|
分布式计算 Hadoop Shell
Hadoop-35 HBase 集群配置和启动 3节点云服务器 集群效果测试 Shell测试
Hadoop-35 HBase 集群配置和启动 3节点云服务器 集群效果测试 Shell测试
477 4
|
SQL 分布式计算 Hadoop
Hadoop-37 HBase集群 JavaAPI 操作3台云服务器 POM 实现增删改查调用操作 列族信息 扫描全表
Hadoop-37 HBase集群 JavaAPI 操作3台云服务器 POM 实现增删改查调用操作 列族信息 扫描全表
321 3
|
分布式计算 Hadoop Shell
Hadoop-36 HBase 3节点云服务器集群 HBase Shell 增删改查 全程多图详细 列族 row key value filter
Hadoop-36 HBase 3节点云服务器集群 HBase Shell 增删改查 全程多图详细 列族 row key value filter
366 3