主流JDK性能大比拼；Zulu OpenJDK/OpenJDK/Oracle JDK/GraalVM CE

￡神魔★判官ぃ 2024-03-24 16:00 6阅读 0赞

市面上可供选择的JVM发行版还是有不少的。选择合适的JVM需要考虑不同的因素。性能是其中一个重要的因素。靠谱的性能研究是很困难的。在本文中，我创建了一个测试，在不同的JVM上执行对比测试。测试程序包括Spring Boot REST应用，使用Prometheus监控JVM并使用Grafana可视化。下图是示意图。除了soapui外，所有东西都在docker容器中运行。

![480ca334b1ac7d86708bd3ab11a010e6.png][]

**隔离干扰因素**  
  
如何确定没有别的因素干扰你的设施。我们可以通过尝试隔离分配给流程的资源来实现。 例如，分配专用CPU和固定数量的内存。 我还进行了几项测试，这些测试将资源限制放在负载均衡器，监控软件和可视化软件上（为这些资源分配不同的CPU和内存）。 为进程分配特定资源（使用docker-compose v2 cpuset和内存参数）似乎不会对单个进程负载和响应时间的度量产生很大影响。 我还比较了启动，负载和无负载情况。 在这些不同情况下，测试结果没有很大变化。  
  
**为进程分配特定CPU和内存**  
  
使用docker-compose无法为进程配置特定CPU。 docker-compose v3不支持为进程分配特定的CPU，也不支持分配资源约束。 您可以想象在潜在的多主机环境中分配特定CPU并非易事。 因此，我将docker-compose文件迁移回v2，该版本允许分配特定的CPU。 可以用于监控软件，这些CPU和JVM使用的CPU隔离开。 我使用了taskset命令。  
  
**同环境测试**  
  
您如何确保所有测试都在完全相同的情况下进行？ 当我针对JVM运行测试而明天再次运行相同的测试场景时，我的结果会有所不同。 这可能有各种原因，例如不同的CPU会占用工作负载，而且这些CPU也忙于处理其他事情，或者我在主机或客户操作系统中运行不同的后台进程。 即使首次测试单个JVM并在测试之后测试另一个JVM，结果也无法比较。 例如，我正在使用Prometheus收集数据。 在第二次运行期间，Prometheus数据库可能会存储更多数据。 这可能会导致添加新数据的速度变慢，这可能会影响第二个JVM性能指标。 这个例子虽然可能相当牵强，但您可以采取措施排除其他因素。 这是我选择同时执行所有测试的原因。  
  
**setup**  
  
我的环境包括一个docker-compose文件，它允许我轻松启动4个在不同JVM上运行Spring Boot应用程序。 在4个JDK的之前，我加了一个haproxy实例来进行负载均衡。 这是为了确保不同的测试之间没有时间相关的差异，保证所有JVM都同时处于相同的负载下。  
  
为了监控结果，我使用了Micrometer保证Prometheus能够读取JVM性能指标。 我使用Grafana对数据可视化：[https://grafana.com/dashboards/4701][https_grafana.com_dashboards_4701]  
  
由于GraalVM目前仅作为JDK 8版本提供，因此其他JVM也使用JDK 8。 当容器运行时，可以通过访问执行器url来检查JVM版本：localhost:8080/actuator/env

![2c74c24cc6ffb0ed5f1b50ed6f3e8575.png][]

或者使用如下命令:

docker exec -it store/oracle/serverjre:8 java -version

使用的JVM版本如下：

*  GraalVM CE rc9 (8u192)
 *  OpenJDK 8u191
 *  Zulu 8u192
 *  Oracle JDK 8u181

**开始测试**  
  
可以在这里下载代码，然后运行命令：

sh ./buildjdkcontainers.sh</pre>
    <pre class="graf graf--pre">docker-compose -f docker-compose-jdks.yml up

你可以可以访问:

*  8080端口的haproxy
 *  9090端口的Prometheus
 *  3000端口的Grafana

需要配置Grafana访问Prometheus的数据

![cea4ff854aa5ce9c965b413024afc841.png][]

接下来配置Grafana中的dashboard:

![bb5a4d78a2936751e83612562b961f4e.png][]

![a8fa967bf1b36b75e96809c220078822.png][]

接下来，您可以对http://localhost:8080/hello（HTTP GET）执行负载测试，并在Grafana仪表板中查看结果。  
  
**操作系统差异**  
  
不同Docker镜像之间使用的OS不同。 操作系统可通过以下方式确定：

docker exec -it store/oracle/serverjre:8 cat /etc/*-release

*  azul/zulu-openjdk:8 used Ubuntu 18.04
 *  oracle/graalvm-ce:1.0.0-rc9 used Oracle Linux Server 7.5
 *  openjdk:8 used Debian GNU/Linux 9
 *  store/oracle/serverjre:8 used Oracle Linux Server 7.5

我认为这不会对JVM运行产生太大的影响。OracleJDK和Graalvm使用相同的操作系统。

### **测试结果** ###

使用JVM dashboard，可以轻松区分特定的差异区域，以便进一步研究它们。

### **cpu使用** ###

![8aa017fe9f1cbddc4d0e21effdb00b7f.png][]

GraalVM在测试期间总体CPU使用率最高。 Oracle JDK的CPU使用率最低。

### **响应时间** ###

整体GraalVM的响应时间最短，OpenJDK最好，紧随Oracle JDK和Zulu。 平均而言，OpenJDK与GraalVM之间的差异约为30％。

![c7ac03a6abd54ed09533f863c927a74a.png][]

### **垃圾回收** ###

GraalVM加载了比其他JDK更多的类。 OpenJDK加载最少的类。 GraalVM和OpenJDK之间的差异大约是25％。 尚未确定这是否是GraalVM的固定开销，或者与所使用的类的数量成比例。

![c7c95c280ca7614c953e8c1bfdef9262.png][]

这些额外的类可能会导致垃圾收集期间的延迟（尽管这种相关性可能不一定是因果关系）。 GraalVM的的GC暂停时间确实最长。  
  
下面是GC暂停时间总和的图表。 由于GraalVM中的分配失败导致了最长的GC暂停时间（顶部的一行）。

![a69128381fee6644ffe4939e1bc9cdbf.png][]

### **内存使用** ###

![241e3348f30bb4c3d705e55b3933870b.png][]

JVM内存使用情况很有意思。 如上图所示，OpenJDK JVM使用的内存堆垛。 GraalVM和Zulu的垃圾收集行为似乎相似，但GraalVM具有更高的内存使用率。 Oracle JDK垃圾收集并不频繁。 在查看平均值时，OpenJDK JVM使用最大内存，而Zulu使用最少内存。 在较长时间内衡量时，Oracle JDK和OpenJDK的行为看起来不稳定，而Zulu和GraalVM看起来更稳定。

![abe503f84f95c2a38ee4f5878931eeb2.png][]

### **总结** ###

在本次测试中，我使用SOAP UI对运行在4个不同JVM上的Spring Boot Rest程序进行了压力测试。我使用Prometheus轮询JVM实例（每5s轮训一次，用Micrometer生成数据），并使用Grafana和Prometheus来显示数据。结果表明GraalVM不适合作为OpenJDK的替代品，因为它的表现更差，使用了更多资源，加载更多类而且垃圾收集时间更长。

*  GraalVM加载的类更多
 *  GraalVM 上的应用程序响应时间最慢
 *  GraalVM的CPU使用率最高（响应时间最慢）
 *  GraalVM的GC时间最长
 *  Zulu OpenJDK使用的内存最少。与Oracle JDK和OpenJDK相比，Zulu OpenJDK和GraalVM的内存使用更稳定。

当然，由于GraalVM相对较新，Micrometer提供的指标可能无法正确显示实际吞吐量和资源使用情况。也可能是我的设置导致这种差异。我通过查看不同情况下的结果来排除第二个问题。  
  
如果您想使用GraalVM的多语言功能，那么其他JVM无此功能。GraalVM也提供了本地编译选项（我在同一个JAR上执行了测试）。此功能可能会大大提高性能。

[480ca334b1ac7d86708bd3ab11a010e6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/80eabd0bd7024f129979b2de8dd84d9b.png
[https_grafana.com_dashboards_4701]: https://link.zhihu.com/?target=https%3A//grafana.com/dashboards/4701
[2c74c24cc6ffb0ed5f1b50ed6f3e8575.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/dc46b646ae1b4ef79d9348a65ee614dc.png
[cea4ff854aa5ce9c965b413024afc841.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/87806e78f4c64d4fa11d9cf5e6134d31.png
[bb5a4d78a2936751e83612562b961f4e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a5a1092b3eb04431aaf4f3ac4e65ce80.png
[a8fa967bf1b36b75e96809c220078822.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/5983200f34af4ce3a0468edd8dd78b0c.png
[8aa017fe9f1cbddc4d0e21effdb00b7f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/7142137fcd4440f5b56a374e13d02ff3.png
[c7ac03a6abd54ed09533f863c927a74a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c812721deec54f0ea03afe8ea341ee88.png
[c7c95c280ca7614c953e8c1bfdef9262.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/baa8c224ac83439488b1da590ced3b56.png
[a69128381fee6644ffe4939e1bc9cdbf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/2aae14b9b7894a3595c09c59a0a6dc01.png
[241e3348f30bb4c3d705e55b3933870b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/80c7d4c0de2e4a10b4010f9ca43206b7.png
[abe503f84f95c2a38ee4f5878931eeb2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/628c791638854d278dd7381a65f8cba9.png