2个月前 (08-10)  jvm |   抢沙发  146 
文章评分 0 次,平均分 0.0
[收起] 文章目录

选择哪种Java虚拟机,HotSpot 还是OpenJ9?两者都是可调的开源JVM实现。HotSpot是一个成熟的JVM实现,最初由Sun Microsystems开发。由IBM开发的OpenJ9在业界的应用并不广泛,但近年来得到了普及。

基于DayTrader7基准测试应用程序研究,OpenJ9声称在启动时间、延迟、吞吐量和内存占用方面表现出色,其中三种经过微调的OpenJ9配置与默认热点进行了比较。

BellSoft的工程师已决定检查是否可以配置HotSpot,以使其显示可比或更好的性能结果。您可以在下面找到他们的测试摘要。

https://github.com/eclipse-openj9/openj9-website/blob/master/benchmark/openjdk11-daytrader7.md

实验设置

我们使用原始研究中的DayTrader7应用程序(https://github.com/WASdev/sample.daytrader7)作为基准。它不是一个微服务应用程序,而是在web服务器上启动的一个小整体,因此我们认为这种配置最为显著。我们还将Linux上的服务器类机器和Windows上的桌面类机器用作平台,并将OpenJDK 11用作JDK二进制文件:采用带有三个OpenJ9标志配置的OpenJDK构建,以及带有默认和调优热点的Liberica JDK。

重点是启动时间占用空间延迟吞吐量。ApacheJMeter 5.4.1用于测量后三个指标。

我们的目标不是通过热点微调技巧生成合成性能数据,而是评估这个JVM实现的标准设置。

结果

启动

有几个参数有助于减少热点应用程序的启动。第一种是应用程序类数据共享或AppCDS。它允许将应用程序类放置在共享存档中,从而加快启动速度。此功能出现在热点1.5中,并在后续版本中得到了改进。例如,现在可以自动生成存档。激活AppCD需要以下标志:

-XX:SharedArchiveFile=app-cds.jsa

请注意,必须显式创建AppCDS存档。上面的参数使您能够指定类存储的存档文件的名称。如果没有它,类将存储在JDK安装目录中,这是不可取的。创建存档后,您可以使用它启动应用程序,JVM将其映射到其内存中,并提供了它所需的大多数类。AppCDS文档可以在Oracle的网站上找到。

此外,-XX:TieredStopAtLevel=1参数使开发人员能够使用客户端(C1)编译器运行应用程序,而无需进行分析,从而提供更快的代码编译。此配置适用于启动加速是最高优先级的情况。

下面是与OpenJ9和HotSpot的启动时间比较。启动时间计算为启动时间与“应用程序daytrader7以X秒为单位启动”输出之间的差值。

测试配置:

  • OpenJ9(1)(堆256MB):“-Xmx256m
  • OpenJ9(2)(堆256 MB,类缓存):“-Xmx256m-Xshareclasses:name=mvn
  • OpenJ9(3)(堆256 MB,类缓存,快速编译):“-Xmx256m-Xshareclasses:name=mvn-Xtune:virtualized-Xscmx200m
  • HotSpot(堆256 MB):“-Xmx256m
  • HotSpot(堆256 MB,AppCDS,C1):“-Xmx256m-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1

HotSpot与OpenJ9:性能比较

具有上述参数的Liberica JDK显示了最好的结果(4.972毫秒),而除了堆大小限制之外没有其他参数的OpenJ9给出了最差的结果(6.986毫秒)。

Footprint

在我们的实验中,我们使用了daytrader7开发人员提供的DayTrader 7.jmx测试计划。根据机器类调整测试计划参数:服务器类机器使用四个线程,桌面类机器使用六个线程。

测试计划是一个脚本,包含许多模仿在线股票交易系统中用户工作的HTTP请求。用户可以登录/注销、查找投资组合或股票报价,以及买卖股票。

在测量统计数据之前,执行了一次虚拟机预热。之后,平均进行5-7次迭代,每次迭代120-300秒,间隔30秒。最后计算平均值。在测量每个配置(预热运行)之前,创建了一个daytrader数据库,其中有15000名用户。在配置度量的每次迭代之前,数据库都被重置。

在负载下测试时,默认热点比OpenJ9消耗更多内存。但是,相同的-XX:SharedArchiveFile=app-cds。jsa和-XX:TieredStopAtLevel=1用于减少启动时间的参数提供了30%的占地面积减少。这是因为C1编译器在代码缓存中使用的内存较少,因为编译后的代码没有额外的中间表达式。由于不同JVM共享的公共类元数据,AppCDS最小化了占用空间。

测试配置:

  • OpenJ9(1)(堆1G):“-Xmx1G
  • OpenJ9(2)(堆1G,类缓存):“-Xmx1G-Xshareclasses:name=mvn
  • OpenJ9(3)(堆1G,类缓存,快速编译):“-Xmx1G-Xshareclasses:name=mvn-Xtune:virtualized-Xscmx200m
  • HotSpot(堆1G):“-Xmx1G
  • HotSpot(堆1G,AppCDS,C1):“-Xmx1G-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1

HotSpot与OpenJ9:性能比较

测试计划包括执行复杂操作的各种查询的组合。图表上的红点表示启动时间。最大堆大小设置为256 MB(Xmx256m标志)。指标是在~126秒时测量的。选择该点是因为不同的热点和OpenJ9配置具有不同的启动时间。应用程序启动后,内存消耗会因负载而增加,然后趋于稳定。正如您在图中所注意到的,OpenJ9在稳定之前展示了内存消耗的飞跃。这是预热所需的内存,这可能会成为一个问题,因为应用程序在稳定状态下消耗的内存比我们预期的要多。因此,如果我们在预热后将内存限制设置为应用程序所需,稳定时间可能会增加,峰值性能会下降。

HotSpot与OpenJ9:性能比较

就leaps而言,它们值得单独研究优化策略。例如,Liberica Lite是我们的LibericaJDK的轻量级版本,它可以为未加载的工作流释放内存,OpenJ9最近收到了JIT作为服务,这使虚拟机能够将多个实例的峰值内存消耗转移到一个编译服务中。

此外,Liberica Lite支持创建微容器,以大幅减少资源消耗。这一指标对于云计算尤其有价值,因为在云计算中,小容器的成本效率相等。一个基于Liberica Lite和Alpine Linux的容器只有42.72MB-是目前市场上最小的!

回到我们的研究,我们的目标是评估稳定条件下的应用程序内存消耗。126秒后,所有虚拟机配置都显示出稳定值,可以测量。从图中可以看出,配置的热点等于或优于两种OpenJ9配置。

延迟和吞吐量

在这组实验中,最大堆大小设置为1 GB(-Xmx1G)。这样,我们可以在一个典型的小型云节点的范围内分析应用程序的行为。

默认热点配置显示了最佳吞吐量(比最佳OpenJ9配置高5%)和延迟(比最佳OpenJ9配置低69%),但在内存消耗方面落后于OpenJ9。-XX:SharedArchiveFile=app-cds.jsa -XX:TieredStopAtLevel=1标志优化了占用指标,但不影响吞吐量和延迟。然而,HotSpot有很多垃圾收集器可供选择,我们可以使用最适合我们的垃圾收集器。在这里,我们切换到串行垃圾收集器(-XX:+UseSerialGC参数),提供了较少的开销。串行GC是最简单的垃圾收集器实现,它只使用一个线程,因此减少了线程开销。它最适用于单处理器机器或具有小堆的应用程序。

此外,为了减少占用空间,我们将InitialHeapSize设置为80MB(Xms80m标志)。

测试配置:

  • OpenJ9(1)(堆1G):“-Xmx1G
  • OpenJ9(2)(堆1G,类缓存):“-Xmx1G-Xshareclasses:name=mvn
  • OpenJ9(3)(堆1G,类缓存,快速编译):“-Xmx1G-Xshareclasses:name=mvn-Xtune:virtualized-Xscmx200m
  • HotSpot(最大堆1G,初始堆80MB):“-Xmx1G-Xms80m
  • HotSpot(最大堆1G,初始堆80MB,AppCDS,C1):“-Xmx1G-Xms80m-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1
  • HotSpot(最大堆1G,初始堆80MB,SerialGC):“-Xmx1G-Xms80m-XX:SharedArchiveFile=app-cds.jsa-XX:TieredStopAtLevel=1-XX:+UseSerialGC

HotSpot与OpenJ9:性能比较

这些指标的测量值约为99.998%。从图中可以看出,默认的热点配置具有最好的指标之一,排名前三(lib-def-xms80m),但结果为-XX:SharedArchiveFile=app-cds.jsa -XX:TieredStopAtLevel=1参数正好相反(lib-xms80m)。尽管如此,即使这种配置也比OpenJ9(1)具有更低的延迟,这显示了最糟糕的结果。然而,具有串行GC的热点(lib-xms80m-SerialGC)在延迟和内存方面显示了最佳结果。

HotSpot与OpenJ9:性能比较

上图显示,G1的默认热点具有最佳吞吐量,但留下了更大的空间。您可以选择使用串行GC或AppCD的配置,以关注更好的延迟或内存占用指标。您还可以使用并行GC,它使用多个线程来加速垃圾收集器,并有助于提高吞吐量。

结论

在所有测试平台上的实验结果相似,并证明配置了HotSpot的Liberica JDK与OpenJ9相当或优于OpenJ9。值得注意的是,在服务器级节点上,默认HotSpot比OpenJ9具有更低的延迟和更高的吞吐量,这有利于长期降低成本。同时,通过切换到另一个VM映像(Alpine Linux使用的RAM是CentOS的两倍)或在项目中引入本机映像技术,可以最小化此配置留下的大量内存占用。

 

除特别注明外,本站所有文章均为老K的Java博客原创,转载请注明出处来自https://javakk.com/2721.html

关于

发表评论

表情 格式

暂无评论

登录

忘记密码 ?

切换登录

注册