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

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

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

网上的Hbase调优资料参差不齐,实在是不忍卒读,有些都是拼凑且版本过时的东西,我这里决定综合所有优质资源进行整合,写一份最全,最有深度,不过时的技术博客。辛苦成文,各自珍惜,谢谢!版权声明:禁止转载,欢迎学习,侵权必究!

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,已经很大了。

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

5 MSLAB效果

使用前:

使用后:发现完全没有Full GC

6 MSLAB效果与G1的协同(锦上添花)

因为G1Gc是在 MSLSB之后发明出来的,但是总体上两者共同使用会有更给力的性能提升:
测试效果:

  • RegionServer堆内存:64KB.
  • JVM回收策略为G1GC
  • 采用MSLAB
  • 不同批量插入测试
  • 50线程:G1GC为1262秒,MSLAB为1132.923秒
  • 100线程:G1GC为2214.201秒,MSLAB为1927.330秒
  • 100线程:G1GC 次数为475次,MSLAB为403次
  • 结论提升了10%到12%

7 总结

本文参考了大量的文档和书籍,辛苦成文不易,尊重原创,谢绝转载,谢谢!

秦凯新 于深圳 201812011847

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

这篇关于HBase Memstore专属JVM策略MSLAB机制深入剖析-OLAP商业环境实战的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!


原文地址:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.chinasem.cn/article/441266

相关文章

Java中Arrays类和Collections类常用方法示例详解

《Java中Arrays类和Collections类常用方法示例详解》本文总结了Java中Arrays和Collections类的常用方法,涵盖数组填充、排序、搜索、复制、列表转换等操作,帮助开发者高... 目录Arrays.fill()相关用法Arrays.toString()Arrays.sort()A

Spring Boot Maven 插件如何构建可执行 JAR 的核心配置

《SpringBootMaven插件如何构建可执行JAR的核心配置》SpringBoot核心Maven插件,用于生成可执行JAR/WAR,内置服务器简化部署,支持热部署、多环境配置及依赖管理... 目录前言一、插件的核心功能与目标1.1 插件的定位1.2 插件的 Goals(目标)1.3 插件定位1.4 核

如何使用Lombok进行spring 注入

《如何使用Lombok进行spring注入》本文介绍如何用Lombok简化Spring注入,推荐优先使用setter注入,通过注解自动生成getter/setter及构造器,减少冗余代码,提升开发效... Lombok为了开发环境简化代码,好处不用多说。spring 注入方式为2种,构造器注入和setter

使用zip4j实现Java中的ZIP文件加密压缩的操作方法

《使用zip4j实现Java中的ZIP文件加密压缩的操作方法》本文介绍如何通过Maven集成zip4j1.3.2库创建带密码保护的ZIP文件,涵盖依赖配置、代码示例及加密原理,确保数据安全性,感兴趣的... 目录1. zip4j库介绍和版本1.1 zip4j库概述1.2 zip4j的版本演变1.3 zip4

从入门到进阶讲解Python自动化Playwright实战指南

《从入门到进阶讲解Python自动化Playwright实战指南》Playwright是针对Python语言的纯自动化工具,它可以通过单个API自动执行Chromium,Firefox和WebKit... 目录Playwright 简介核心优势安装步骤观点与案例结合Playwright 核心功能从零开始学习

Java堆转储文件之1.6G大文件处理完整指南

《Java堆转储文件之1.6G大文件处理完整指南》堆转储文件是优化、分析内存消耗的重要工具,:本文主要介绍Java堆转储文件之1.6G大文件处理的相关资料,文中通过代码介绍的非常详细,需要的朋友可... 目录前言文件为什么这么大?如何处理这个文件?分析文件内容(推荐)删除文件(如果不需要)查看错误来源如何避

SpringBoot整合Dubbo+ZK注册失败的坑及解决

《SpringBoot整合Dubbo+ZK注册失败的坑及解决》使用Dubbo框架时,需在公共pom添加依赖,启动类加@EnableDubbo,实现类用@DubboService替代@Service,配... 目录1.先看下公共的pom(maven创建的pom工程)2.启动类上加@EnableDubbo3.实

SpringBoot整合(ES)ElasticSearch7.8实践

《SpringBoot整合(ES)ElasticSearch7.8实践》本文详细介绍了SpringBoot整合ElasticSearch7.8的教程,涵盖依赖添加、客户端初始化、索引创建与获取、批量插... 目录SpringBoot整合ElasticSearch7.8添加依赖初始化创建SpringBoot项

JAVA覆盖和重写的区别及说明

《JAVA覆盖和重写的区别及说明》非静态方法的覆盖即重写,具有多态性;静态方法无法被覆盖,但可被重写(仅通过类名调用),二者区别在于绑定时机与引用类型关联性... 目录Java覆盖和重写的区别经常听到两种话认真读完上面两份代码JAVA覆盖和重写的区别经常听到两种话1.覆盖=重写。2.静态方法可andro

SpringBoot中六种批量更新Mysql的方式效率对比分析

《SpringBoot中六种批量更新Mysql的方式效率对比分析》文章比较了MySQL大数据量批量更新的多种方法,指出REPLACEINTO和ONDUPLICATEKEY效率最高但存在数据风险,MyB... 目录效率比较测试结构数据库初始化测试数据批量修改方案第一种 for第二种 case when第三种