微服务中使用 OpenJ9 JVM 内存占用降60%(相对HotSpot)

随着微服务的普及,许多企业踏上微服务之旅。

微服务化后,应用数量可能高一个数量级。一般企业,以前三五个应用能支撑业务,微服务化之后应用数量可能多达几十个。
每个微服务往往独立部署,内存的消耗自然也高居不下,以前两台8核16G机器指不定就能跑起来,现两台16核64G还不一定够用,同时由于多套环境的存在加上容器编排工具(如K8s)所需的资源,硬件资源的投入自然是成倍增加。

在 Web 应用开发中,为了降低内存消耗,你是否尝试过:

  • 去除不必要的组件,减少代码体积
  • 更换 Web 容器,如将 Tomcat 更换为Undertow
  • 优化Docker基础镜像,减少镜像体积

这些效果往往不是很理想。本篇介绍 OpenJ9 JVM,通过将 HotSpot 更换为 OpenJ9,内存占用能降低至少 60%,而启动时间也能快 40% 以上,效果立竿见影。

OpenJ9 简介

OpenJ9 的前身是IBM的 J9 Java 虚拟机,主要服务于IBM企业级软件产品,是一款高性能的JVM。

2017年9月,IBM 将 J9 JVM 捐献给 Eclipse 基金会,并更名 Eclipse OpenJ9,开启开源之旅。

OpenJ9 擅长于内存管理,同时针对容器化做了很多工作,按官方说法是: more container-aware 。

下面摘自 OpenJ9 的 Release History,选择了部分内容,可快速一览:

  • 2017.11 支持使用 OpenJDK8 构建 OpenJ9

  • 2018.3 发布 0.8.0:OpenJ9 开始支持各平台(Mac、Linux、Windows等) 的 OpenJDK 8,宣布在JDK8中,比HotSpot 42% faster startup and a footprint at least 60% smaller

  • 2018.8 发布 0.9.0:支持 OpenJDK 10;对Docker容器支持更友好;在运行一些Eclipse性能测试时,比HotSpot JVM快 43%,少用42%的内存.

  • 2018.10 发布 0.10.0:支持 OpenJDK 11,开始适配 HotSpot JVM的一些参数配置

  • 2018.10 发布 0.11.0:改善AOT性能、针对运行在容器中的应用内存优化、 “pause-less” GC mode for response-time sensitive, large heap applications

  • 2019.2 发布 0.12.1 :提示RSA算法加密性能;性能进一步提升

  • 2019.3 发布 0.13.0:支持OpenJDK 12; 支持jps命令;支持将Java dump 文件写入STDOUT/STDERR

官方性能报告

下面是 OpenJ9官方的基准测试结果(完整报告),包含启动时间、响应时间、吞吐量等指标。

66% smaller footprint after startup

由于减少内存占用的重要性,OpenJ9 对云负载(cloud wordloads)做了深度优化,在应用启动后,占用内存比HotSpot 约少 66%。

66% smaller footprint after startup

由于减少内存占用的重要性,OpenJ9 对云负载(cloud wordloads)做了深度优化,在应用启动后,占用内存比HotSpot 约少 66%。

img

63% smaller footprint during ramp up

应用负载增加时,内存都会骤增。但状态稳定后,使用 OpenJ9 的OpenJDK 8 比使用 HotSpot 的 OpenJDK 8 减少了约 63% 的物理内存

img

42% faster startup time

Shared classesAhead-of-Time(AOT) 技术的应用显著减少了应用启动时间。通过使用 -Xquickstart 参数(启用AOT),启动时间可以减少高达42%

img

Comparable throughput

在做吞吐量对比时,二者峰值吞吐量差不多,但使用OpenJ9 的 OpenJDK 8 大约快1分钟达到峰值。

img

Faster ramp-up time in the cloud

在云环境下,虚拟化技术被广泛使用,一台大的机器经常被切割成若干小的虚拟机,这些虚拟机往往做了资源限制。OpenJ9 在单核CPU上用了8.5分钟达到峰值吞吐量,而 HotSpot用了30分钟。对于在资源受限的环境下(如云环境)跑 short-lived VMs,能够更快的完成更多工作就显得更为重要。

资源受限的一大副作用就是 Java应用花费更长的启动时间(受JIT影响)

笔者注:内存限制时,应用甚至会无法启动,导致不断重启。

img

性能测试

创建一个 Spring Boot Web 应用并打成jar包,分别使用 HotSpot、OpenJ9 虚拟机的 Open JDK8 结合Docker来做测试。

基于OpenJ9的Dockerfile

1
2
3
FROM adoptopenjdk/openjdk8-openj9:alpine-slim
COPY target/app.jar /app.jar
ENTRYPOINT java $JAVA_OPTS -Xshareclasses -Xquickstart -jar /app.jar

基于HotSpot的Dockerfile

1
2
3
FROM openjdk:8u181-jre-slim-stretch
COPY target/app.jar /app.jar
ENTRYPOINT java $JAVA_OPTS -jar /app.jar

启动容器后,docker stats openj9 hotspot 查看容器资源使用情况如下:

img

OpenJ9 是 50.89M;HotSpot 是235.7M,差异非常大。

下面是我们测试环境中的一个普通应用(使用Docker运行)的测试结果。

基于 Open JDK8 (HotSpot) 时内存消耗稳定在 1G左右

img

基于 OpenJDK8(OpenJ9)时内存消耗稳定在 300M左右

img

该怎么切换到 OpenJ9 ?

如果使用Docker,直接更换基础镜像即可,容器场景下更能发挥 OpenJ9 的作用。

如果JDK直接安装在服务器上,可以直接在 AdoptOpenJDK 上下载相应的介质。

对于 JVM Options,可以参考做一些调整。

对开发人员的影响有哪些?

大家一般接触的都是HotSpot VM,且对于其理论、JVM参数、命令行工具甚至性能调优等相对比较熟悉,这块资料也比较丰富。

OpenJ9 以前更多的是支持IBM企业级的商业产品,大家了解相对较少,连日用命令行工具暂时都只提供了jps、jstack,不过可以使用像阿里 arthas 这类Java应用诊断工具,效果也是一样的。

对于小企业来说,JVM一般不是瓶颈,而更换JVM所带来的IT成本投入减少确是实实在在的,尤其是对于初创团队,自然是能省则省。

ApiBoot v2.2.5版本无法兼容Hoxton.SR5的SpringCloud Gateway

使用ApiBoot最新发布的v2.2.5版本整合SpringCloud GatewayHoxton.SR5版本时导致项目无法启动,控制台抛出的错误如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
***************************
APPLICATION FAILED TO START
***************************

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

org.springframework.boot.web.embedded.netty.NettyReactiveWebServerFactory.lambda$createHttpServer$0(NettyReactiveWebServerFactory.java:158)

The following method did not exist:

reactor.netty.tcp.TcpServer.bindAddress(Ljava/util/function/Supplier;)Lreactor/netty/tcp/TcpServer;

The method's class, reactor.netty.tcp.TcpServer, is available from the following locations:

jar:file:/Users/yuqiyu/.m2/repository/io/projectreactor/netty/reactor-netty/0.9.6.RELEASE/reactor-netty-0.9.6.RELEASE.jar!/reactor/netty/tcp/TcpServer.class

The class hierarchy was loaded from the following locations:

reactor.netty.tcp.TcpServer: file:/Users/yuqiyu/.m2/repository/io/projectreactor/netty/reactor-netty/0.9.6.RELEASE/reactor-netty-0.9.6.RELEASE.jar


Action:

Correct the classpath of your application so that it contains a single, compatible version of reactor.netty.tcp.TcpServer

从控制台打印的错误信息我们可以发现这是版本不兼容的问题导致的,reactor-netty作为SpringCloud Gateway的重要组成部分之一,为什么会出现版本不兼容的问题呢?

reactor-bom

我们在构建项目时,SpringBoot使用最新发布的v2.3.1,在v2.3.1版本的spring-boot-dependencies固化版本依赖模块内定义reactor-bom的依赖,如下所示:

1
2
3
4
5
6
7
<dependency>
<groupId>io.projectreactor</groupId>
<artifactId>reactor-bom</artifactId>
<version>${reactor-bom.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>

${reactor-bom}占位符对应的使用版本为Dysprosium-SR8,通过查看reactor-bom内定义的依赖列表发现了reactor-netty的踪迹,而它对应的版本为v0.9.8,如下所示:

1
2
3
4
5
<dependency>
<groupId>io.projectreactor.netty</groupId>
<artifactId>reactor-netty</artifactId>
<version>0.9.8.RELEASE</version>
</dependency>

那为什么我们在启动项目时控制台抛出了使用v0.9.6版本的reactor-netty导致不兼容的问题呢?

项目依赖的reactor-netty版本

查看idea开发工具内项目的External Libraries发现,项目编译时使用的reactor-netty的版本确实是为v0.9.6,如下图所示:

SpringCloud Gateway依赖的reactor-netty版本

Hoxton.SR5版本的spring-cloud-dependencies依赖内使用的spring-cloud-gateway版本为2.2.3.RELEASE,我们从GitHub拉取spring-cloud-gateway源码到本地,使用idea工具打开项目并切换到2.2.x分支后发现External Libraries依赖列表内所使用的reactory-netty版本为v0.9.7这是编译spring-cloud-gateway时所依赖的版本

spring-cloud-gateway仓库在GitHub的地址为:git@github.com:spring-cloud/spring-cloud-gateway.git

问题分析

  1. 从上面的分析步骤中我们发现,spring-cloud-gateway编译时所使用的reactory-netty版本为v0.9.7,而v2.3.1版本的SpringBoot所使用的reactory-netty版本为v0.9.8,依赖的版本是支持向下兼容的,所以这样不会出现什么问题。

  2. 但是我们项目在编译时使用的reactory-netty版本却为v0.9.6,版本肯定是不支持向上兼容的,所以才导致了项目启动时控制台打印的不兼容异常。

问题定位

ApiBoot的固化版本依赖api-boot-dependencies内默认添加了SpringCloud的依赖,为了方便项目集成SpringCloud时使用组件,不过这也导致了这个问题的发生。

v2.2.5版本的ApiBoot内集成的SpringCloud版本为Hoxton.RELEASE,要比Hoxton.SR5版本发布的更早,它所使用的reactory-netty依赖版本为v0.9.6

解决问题

既然找到了问题,对症下药,解决起来就容易了,我们只需要把项目中所依赖的reactory-netty版本修改为v0.9.6以上版本即可,在项目的pom.xml内添加如下依赖:

1
2
3
4
5
6
7
8
9
10
<dependencyManagement>
<!--省略其他依赖-->
<dependencies>
<dependency>
<groupId>io.projectreactor.netty</groupId>
<artifactId>reactor-netty</artifactId>
<version>0.9.8</version>
</dependency>
</dependencies>
</dependencyManagement>

SpringCloud基础教程专题

被访问0


关于专题

SpringCloud目前有两个主流的体系:原生体系Alibaba体系,本专题会涵盖这两个主流体系的核心技术讲解文章,提供给大家一整套的微服务架构搭建以及部署方案

自定义你自己的Eureka管理界面

Eureka服务端的界面是可以自定义的,而且方式比较简单,下面我们来看下修改方式。

长期免费开放一台Nacos Server服务

恒宇少年准备着手更新SpringCloud Alibaba系列文章教程,为了方便大家的学习特意免费长期开放了一台Nacos Server,可以用来当做服务注册中心使用,也可以当做配置中心使用。

长期免费开放一台Eureka Server服务

恒宇少年为了大家学习SpringCloud方便,特意给大家提供了一个在线开放的Eureka Server服务,大家可以直接在学习使用服务注册时配置使用开放的Eureka Server进行服务注册。

SpringCloud与Seata分布式事务初体验

在本篇文章中我们在SpringCloud环境下通过使用Seata来模拟用户购买商品时由于用户余额不足导致本次订单提交失败,来验证下在MySQL数据库内事务是否会回滚

阿里巴巴分布式事务利器Seata环境准备

阿里巴巴自从跟SpringCloud共同发起创建微服务开源社区时,开启了SpringCloud Alibaba分支,而且在生态内提供了一款适用于分布式应用程序(DubboSpringCloud等)的事务框架Seata,该框架经过多个大版本的发布,已经支持MySQLOracle这两种数据库事务回滚(Rollback)以及提交(Commit)控制,每次发版都会修复一些用户反馈的Issue以及添加一些新特性。

搭建Eureka服务注册中心

Eureka服务注册中心是netflix开源组织提供的一个服务高可用的解决方案,在前端时间一直在疯传的2.0开源流产的问题,其实并不影响我们的使用,netflix只不过是不再维护2.0分支的开源代码,所以做出了免责声明,不过对于我们使用者来说确实比较担心这一点,还有不少人更换服务注册中心,比如:zookeeperconsul

SpringCloud Gateway整合Eureka转发服务请求

在上一篇文章SpringCloud Gateway路由转发规则中我们讲解了SpringCloud Gateway内部提供的断言、谓语,让我们可以组合更精确的业务场景进行请求,既然SpringCloud GateWay担任了网关的角色,在之前Zuul可以通过服务名进行自动转发,SpringCloud Gateway是否可以实现自动转发呢?

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×