前言：

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

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

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

这些效果往往不是很理想。而通过将 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%。
在这里插入图片描述
63% smaller footprint during ramp up

应用负载增加时，内存都会骤增。但状态稳定后，使用 OpenJ9 的OpenJDK 8 比使用 HotSpot 的 OpenJDK 8 减少了约 63% 的物理内存
在这里插入图片描述
42% faster startup time

Shared classes 和 Ahead-of-Time(AOT) 技术的应用显著减少了应用启动时间。通过使用 -Xquickstart 参数(启用AOT)，启动时间可以减少高达42%。
在这里插入图片描述
Comparable throughput

在做吞吐量对比时，二者峰值吞吐量差不多，但使用OpenJ9 的 OpenJDK 8 大约快1分钟达到峰值。
在这里插入图片描述
Faster ramp-up time in the cloud

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

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

注： 内存限制时，应用甚至会无法启动，导致不断重启。
在这里插入图片描述

对开发人员的影响

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

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

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

进入正题：

使用 OpenJ9 之前微服务内存消耗：
在这里插入图片描述
使用 OpenJ9 之后微服务内存消耗：
在这里插入图片描述
这个项目总共是19个微服务，分别部署在两台云服务器上，没有使用 OpenJ9 之前服务还没部署完，内存就已经消耗殆尽，再购买内存吧，又得控制成本，最后不得不使用 OpenJ9，使用之后确实内存占用率降低太多了，目前这台服务器注册了13个服务，内存占用率还不到之前的1/3，真是太给力了。

切换到 OpenJ9 方便吗

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

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

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

切换过程：

1.修改Dockerfile文件

2.重新制作微服务镜像

3.上传镜像至harbor仓库

4.书写docker yaml文件管理服务

1.修改Dockerfile文件

基础镜像：adoptopenjdk/openjdk8-openj9

[root@biz ~]# cd /mnt/app/docker-images/

[root@biz docker-images]# sed -i '1s#anapsix/alpine-java:8_server-jre_unlimited#172.xx.xxx.xxx/dev/adoptopenjdk/openjdk8-openj9:alpine-slim#' blade-travel-handover/Dockerfile

[root@biz docker-images]# cat blade-fleet-handover/Dockerfile
FROM 172.xx.xxx.xxx/dev/adoptopenjdk/openjdk8-openj9:alpine-slim
RUN mkdir -p /blade/blade-fleet-handover
WORKDIR /blade/blade-fleet-handover
EXPOSE xxxx
ADD ./target/blade-fleet-handover.jar ./app.jar
CMD java -jar app.jar
......

2.制作微服务镜像

[root@biz docker-images]# cd ../blade-travel-handover/

[root@biz blade-travel-handover]# docker build -t blade-travel-handover:v1.1.0 .

[root@biz blade-travel-review]# docker images
REPOSITORY                    TAG                      IMAGE ID            CREATED              SIZE
......
blade-travel-handover        v1.1.0                   c6dbea1e4001        2 minutes ago        185MB
......

3.上传新版镜像至harbor仓库

[root@biz shell]# vim push_back.sh   
                    //由于镜像太多，使用脚本上传镜像到harbor仓库
#!/bin/bash
Version=v1.1.0
IP_dev="172.xx.xxx.xxx/dev"
Image_name=`docker images |grep -v "^172.xx.xxx.xxx" |awk 'NR>1{print $1}'`
for i in ${Image_name[@]}
do
docker tag ${i}:$Version  ${IP_dev}/${i}:$Version
sleep 1
docker push ${IP_dev}/${i}:$Version
done
exit 0

[root@biz shell]# bash push_back.sh

[root@biz shell]# docker images
REPOSITORY                                        TAG                      IMAGE ID            CREATED             SIZE
......
172.xx.xxx.xxx/dev/blade-travel-handover          v1.1.0                   c6dbea1e4001        9 minutes ago       185MB
blade-travel-handover                             v1.1.0                   c6dbea1e4001        9 minutes ago       185MB
......

在这里插入图片描述
在这里插入图片描述
4.书写docker yaml文件管理服务

[root@biz docker_yaml]# vim docker_start.yaml
......
blade-fleet-handover:
    image: 172.xx.xxx.xxx/dev/blade-fleet-handover:v1.1.0
    container_name: blade-fleet-handover
    network_mode: "host"   //网络模式使用host，即容器网络与主机网络共享
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime    //本机时间文件路径映射至docker
      - /etc/timezone:/etc/timezone     //本机所属时区文件映射至docker
    ports:
    - "xx:xx"
 ......

[root@biz docker_yaml]# docker-compose -f docker_start.yaml up -d    //指定yaml文件来管理docker服务

[root@biz docker_yaml]# docker ps
CONTAINER ID        IMAGE                                              COMMAND                  CREATED             STATUS              PORTS               NAMES
172.xx.xxx.xxx/dev/blade-fleet-handover:v1.1.0     "/bin/sh -c 'java -j…"   15 hours ago        Up 15 hours                             blade-fleet-handover
......

[root@biz ~]# free
              total        used        free      shared  buff/cache   available
Mem:       15732704     4955076     7522760        1212     3254868    10395420
Swap:             0           0           0

[root@biz ~]# free -g     //以G单位显示内存消耗情况
              total        used        free      shared  buff/cache   available
Mem:             15           4           7           0           3           9
Swap:             0           0           0

总结：

上面简单的列举了这次切换 OpenJ9 的过程，因为我们使用的是Docker，所以切换 OpenJ9 相对不是那么麻烦，最重要的是结果还是令人非常满意的。

↓↓↓↓↓↓

最近刚申请了个微信公众号，上面也会分享一些运维知识，大家点点发财手关注一波，感谢大家。 【原创公众号】：非著名运维 【福利】：公众号回复 “资料” 送运维自学资料大礼包哦！
在这里插入图片描述

标签: 内存, docker, root, 占用率, HotSpot, handover, blade, OpenJ9

相关文章推荐

添加新评论，含*的栏目为必填