京东JDK在大数据平台的探索与研究
|
由于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停顿时间： （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
