内容简介:本套技术专栏是作者(秦凯新)平时工作的总结和升华,通过从真实商业环境抽取案例进行总结和分享,并给出商业应用的调优建议和集群环境容量规划等内容,请持续关注本套博客。期待加入IOT时代最具战斗力的团队。QQ邮箱地址:1120746959@qq.com,如有任何学术交流,可随时联系。网上的Hbase调优资料参差不齐,实在是不忍卒读,有些都是拼凑且版本过时的东西,我这里决定综合所有优质资源进行整合,写一份最全,最有深度,不过时的技术博客。辛苦成文,各自珍惜,谢谢!版权声明:禁止转载,欢迎学习,侵权必究!垃圾回收器
本套技术专栏是作者(秦凯新)平时工作的总结和升华,通过从真实商业环境抽取案例进行总结和分享,并给出商业应用的调优建议和集群环境容量规划等内容,请持续关注本套博客。期待加入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,如有任何学术交流,可随时联系。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- CoreOS 实战:剖析 etcd
- CoreOS 实战:剖析 etcd
- 别人家的 InfluxDB 实战 + 源码剖析
- OLAP技术之Kylin官方案例详细剖析-商业环境实战
- Kylin官方案例详细剖析及剪枝优化-OLAP商业环境实战
- Elasticsearch生产环境索引管理深入剖析-搜索系统线上实战
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
挑战程序设计竞赛
秋叶拓哉、岩田阳一、北川宜稔 / 巫泽俊、庄俊元、李津羽 / 人民邮电出版社 / 2013-7-1 / CNY 79.00
世界顶级程序设计高手的经验总结 【ACM-ICPC全球总冠军】巫泽俊主译 日本ACM-ICPC参赛者人手一册 本书对程序设计竞赛中的基础算法和经典问题进行了汇总,分为准备篇、初级篇、中级篇与高级篇4章。作者结合自己丰富的参赛经验,对严格筛选的110 多道各类试题进行了由浅入深、由易及难的细致讲解,并介绍了许多实用技巧。每章后附有习题,供读者练习,巩固所学。 本书适合程序设计......一起来看看 《挑战程序设计竞赛》 这本书的介绍吧!