企业实战(7)微服务中改用 OpenJ9 JVM 将内存占用率降低60%(相对HotSpot)
2021/6/12 7:22:09
本文主要是介绍企业实战(7)微服务中改用 OpenJ9 JVM 将内存占用率降低60%(相对HotSpot),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
前言:
随着微服务的普及,许多企业踏上微服务之旅。微服务化后,应用数量可能高一个数量级。一般企业,以前三五个应用能支撑业务,微服务化之后应用数量可能多达几十个。每个微服务往往独立部署,内存的消耗自然也高居不下,以前两台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 相对不是那么麻烦,最重要的是结果还是令人非常满意的。
↓↓↓↓↓↓
最近刚申请了个微信公众号,上面也会分享一些运维知识,大家点点发财手关注一波,感谢大家。 【原创公众号】:非著名运维 【福利】:公众号回复 “资料” 送运维自学资料大礼包哦!
这篇关于企业实战(7)微服务中改用 OpenJ9 JVM 将内存占用率降低60%(相对HotSpot)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-05-20测试人员都是画画大神,让我看看谁还不会用代码图?
- 2024-05-20年薪百万的程序员都在用的摸鱼方式……
- 2024-05-19永别了,微服务架构!
- 2024-05-15鸿蒙生态设备数量超8亿台
- 2024-05-13TiDB + ES:转转业财系统亿级数据存储优化实践
- 2024-05-09“2024鸿蒙零基础快速实战-仿抖音App开发(ArkTS版)”实战课程已上线
- 2024-05-09聊聊如何通过arthas-tunnel-server来远程管理所有需要arthas监控的应用
- 2024-05-09log4j2这么配就对了
- 2024-05-09nginx修改Content-Type
- 2024-05-09Redis多数据源,看这篇就够了