加入收藏 | 设为首页 | 会员中心 | 我要投稿 东莞站长网 (https://www.0769zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 网站设计 > 教程 > 正文

京东JDK在大数据平台的探索与研究

发布时间:2019-03-17 05:25:04 所属栏目:教程 来源:臧琳
导读:本文旨在概述京东在JDK方向上的尝试与探索,以及京东JDK项目背景,基本特性以及未来的工作方向。对于JDK特性的技术讨论,实现细节及效果,将在后续系列文章中深入讨论。 一、HDFS简介 HDFS是作为最底层的分布式存储服务而存在的,是Hadoop的分布式文件系统

由于openJDK的限制,针对G1GC的region大小最大只能达到32MB, 并且JVM内部推荐的region个数为2048, 即G1GC最为适用的堆大小在64GB (2048*32MB),而业务量要求NameNode堆至少要在180GB,因此JDJDK确定了优化G1GC对于大堆的支持的目标,以期望提高管理结点的性能。

经过调查研究,针对G1GC的region调整,实际上有两种方向,一种是保持region大小不变,增大region的个数以适应大堆,比如针对180GB的堆,region大小保持在32MB不变,那么就需要创建5760个region。此方案的好处是保持region大小不变,可以将分配的影响降到最小,但同时由于G1算法需要对每个region之间的引用关系做同步,如果堆数量过多,则同步的开销增大,从而影响GC的效率。

另一种方案是增加region大小,以保持region个数保持在2048或少量增长,其特点是增大region可能会导致应用程序对象分配的行为改变,但对于region间引用关系的同步影响比较小。

为了能够达到优化性能的目标,对NameNode做了如下分析:通过采集GCdebug的日志信息,可以看到NameNode的对象分配速率非常频繁,old space allocation rate 达到1MB/s,即有大量的object被频繁提升到老年代,同时存在大量的TLAB refile以及出现TLAB fill的频率在每分钟3万次左右,TLAB fill 即allocation进入slow path,需要进行TLAB的替换或者在非TLAB中分配。因此对象的分配性能是NameNode 性能的关键点之一。

结合以上分析,对JDK的region大小上限进行了优化,同时针对region大小,对G1进行了相应的修改。以下为优化后的实验得到的数据。

可以看到,TLAB fill次数从每分钟30000降到了20000,即对象分配在slow path的机率减少了33%。

(3) 针对多线程下锁的性能优化:

在JDJDK版本升级后, 运维与研发人员在大数据平台运行过程中,发现G1在运行过程中会出现2s左右的超长YoungGC,而相同规模的YGC大部分只有200ms左右. 如下图中绿线所示。

经过分析, G1出现2s GC的主要原因在于偏向锁功能的revoke过于频繁。利用JFR可以看到如下现象。

综合以上分析, 在管理节点采用-XX:-UseBiasedLocking后, 2s的GC 消失, 上图蓝色线条所示。

(4) Java堆的动态拓展:

Java程序在启动时要求程序员为JVM预设堆内存上限,即指定-Xmx的大小(或采用默认JVM参数)。但在实际使用过程中,很难清晰的计算出究竟应该采用多大的Java堆上限,尤其是对于线上系统中的管理进程,很有可能在发生大量的业务请求时出现OOM(Out-Of-Memory)异常而导致管理进程退出,出现灾难性后果。另一方面,考虑到系统资源占用,Java程序往往要求JVM不要占用大量的系统内存,即使-Xmx的值小于RAM的大小,所以在程序运行时,经常会出现Java进程因为OOM退出,而系统RAM却还有很多剩余可以利用。

为了缓解OOM的问题,京东JDK研发了基于G1GC的动态拓展堆大小的功能。 该功能在JVM堆内存使用率正常的情况下,维持java堆在-Xmx之下,而当JVM发现当前进程Java堆被大量占用时,将发出警报,从而运维人员可以根据当前业务情况即系统RAM使用情况,动态的打开Java堆拓展功能,JVM将Java堆进行一定比例的拓展,以保证JVM顺利度过业务繁忙的时段。 当业务量降低,并且heap使用率低于一定阈值时,JVM将利用G1GC回收拓展的堆区域,从而保证在正常情况下JVM进程不会给系统内存造成额外的压力。

(5) 定期、定时触发GC:

经过调研,发现京东的业务呈现明显的时间周期性,比如某个集群在某一时段基本处于空闲状态。而在繁忙状态时,堆内存以及CPU资源都集中于业务的处理,如果此时发生OldGC或者FullGC,或者YoungGC发生过于频繁,都会导致系统的业务处理能力下降。

为了降低GC对于业务处理能力的影响,京东JDK基于G1GC开发了周期性GC的功能。运维人员可以在每天系统不繁忙的时间段定时触发多次YoungGC以及必要的MixedGC/FullGC来清里Java堆中的垃圾,从而降低高峰时段GC触发的频率及时间。

(6) JVM及时归还未使用的内存(Uncommitted Memory)给系统:

JDK12特性,京东JDK目前已经支持。此功能主要为节省物理内存空间。JDK11版本中的G1并不会及时的将空的region交还给OS,只有在FullGC或Old GC的concurrent 阶段才会交还已经回收的region给OS。但由于G1的设计目标就是避免FullGC以及尽量少的触发OldGC,所以实际运行过程中,G1 堆占用的物理内存会迟迟不能释放给系统,导致JVM进程占用内存远高于实际使用量。在多进程多任务环境中,会整体导致系统内存资源不能有效分配及使用,同时提高内存硬件的需求量,增加企业的成本投入。

京东JDK在JDK11的基础上,从JDK12引入了JEP346特性 --“及时回收未使用的Uncommitted Memory给系统“这个特性,其在JVM内部引入了监测机制,当发现系统空闲以及JVMGC触发不频繁时,JVM会自动触发concurrentGC 或FullGC来回收uncommitted region给系统。

(7) 可撤销的G1 Mixed GC以保证GC停顿时间:

(编辑:东莞站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读