OpenJ9 和 docker 容器？答案

【问题标题】：OpenJ9 and docker containers?OpenJ9 和 docker 容器？
【发布时间】：2017-10-17 05:53:02
【问题描述】：

从历史上看，HotSpot 在 docker 容器中运行的记录很差，会误判分配的资源（例如 RAM）。不过，情况正在慢慢好转。

OpenJ9 如何与 docker 容器保持一致，以及它在多大程度上了解容器提供的资源（内存、套接字、线程等）

此外，在 JavaOne 2017 演示中提到 OpenJ9 可以跨不同的 OpenJ9 VM 缓存 jit 编译的类。当虚拟机被限制在不同的容器中时（或）如果容器化的 JVM 共享一个 docker 卷，这种共享缓存是否可能？

【问题讨论】：

标签： openj9

【解决方案1】：

目前正在处理容器支持，如需了解 cgroup，请查看PR。这也将导致添加容器支持。
关于共享类缓存 (SCC)，这两种情况都是可能的。请参阅here 中的“使用类数据共享功能”以获取共享 docker 卷的示例。当 JVM 被限制在没有共享卷的不同容器中时，建议构建预先构建 SCC 的 docker 容器。您的 dockerfile 将如下所示。

FROM 采用openjdk/openjdk9-openj9:x86_64-alpine-jdk-9.181

运行 mkdir /opt/shareclasses && mkdir /opt/app

复制 japp.jar /opt/app

CMD ["java", "-Xshareclasses:cacheDir=/opt/shareclasses", "-jar", "/opt/app/japp.jar"]

然后您需要构建和运行映像并提交生成的容器并将其作为您的基础映像。

docker build -t japp:latest . docker run japp docker commit container_id japp

【讨论】：

【解决方案2】：

可以创建共享类缓存并将其包含在 Docker 文件中。

共享类缓存可以在开发或预生产环境中创建，或者在应用程序上运行一些测试时。 在 Pre-prod 中创建缓存可能更有效，但是在构建过程中通过测试来实现它要简单得多。我使用 Spring Boot 应用程序对其进行了测试，即使是任何新生成的 Spring Boot 项目中包含的简单“contextLoads”测试都会产生巨大的影响。

这是一个使用 Maven 进行测试的示例，但同样的 VM 选项也可以用于不同的场景。

1.在启用共享类缓存的情况下运行测试：

你可以在 Maven 中使用 Surefire 插件来完成，我不确定如何使用 Gradle 来完成

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <argLine>-Xquickstart -Xshareclasses:cacheDir=classCache,name=appname -Xscmx32m </argLine>
  </configuration>
</plugin>

VM 参数：-Xquickstart -Xshareclasses:cacheDir=classCache,name=appname -Xscmx32m

cacheDir 子选项用于指定缓存文件夹，以便更轻松地包含在 Docker 映像中
name 子选项用于避免难以预测的自动缓存名称
-Xscmx 选项用于限制缓存大小，这应该针对应用程序进行调整，在启动速度和图像大小之间进行权衡
-Xquickstart 选项指示 JVM 在与 -Xshareclasses 选项结合使用时尽可能多地执行 AOT

您可以使用 printStats 子选项检查使用了多少缓存大小，如下所示：java -jar -Xshareclasses:cacheDir=classCache,name=appname,readonly ,printStats application.jar

2。将预热缓存添加到 Docker 映像

只需将cacheDir子选项设置的目录添加到图片中在本例中为classCache

ADD classCache classCache

由于这些文件每次都会改变，classCache应该最后添加到图像中

并且使用缓存运行应用程序

ENTRYPOINT exec java -Xquickstart -Xtune:virtualized -Xshareclasses:cacheDir=classCache,name=appname,readonly -jar application.jar

VM 参数：-Xquickstart -Xtune:virtualized -Xshareclasses:cacheDir=classCache,name=appname,readonly -jar application.jar

缓存可以通过classCache和name子选项指定，没有这些，JVM可能会创建一个新的缓存文件夹并忽略添加到图像中的那个。

根据我的经验，readonly 选项使它有点更快，但这不是绝对必要的。因为当容器被销毁时这个缓存会被删除，所以没有必要持久化这些canges。

-Xquickstart 和 -Xtune:virtualized 选项可进一步优化容器中的启动速度

【讨论】：