记一次 JVM 参数调整导致 ShardingSphere-Proxy 性能下降的问题排查过程

问题现象

在性能测试中,分别对两个版本差异间隔一天的 ShardingSphere-Proxy 做性能测试,发现版本更新的 Proxy 比旧的 Proxy 在 TPC-C 场景下峰值 tpmC 下降了 7% 左右。

排查过程

在性能测试期间,使用 async-profiler 分别对两个进程进行采样。

火焰图未发现明显代码路径异常

使用 IDEA 对比火焰图差异,发现性能下降的 Proxy 在 I/O 相关调用的比例略微减少(绿色部分),在 ShardingSphere 计算逻辑的比例略微增加(红色部分)。

但是,从火焰图看并没有发现性能下降的 Proxy 有什么新增的逻辑。

CPU 使用率存在细微差异

async-profiler 采样期间,每秒会读取一次 JVM 进程的用户态/内核态的 CPU 使用率,以及系统 CPU 使用率。

有时候,从 CPU 使用率的细微差异可以发现一些异常。

性能正常的 ShardingSphere-Proxy

记一次 JVM 参数调整导致 ShardingSphere-Proxy 性能下降的问题排查过程_第1张图片

性能下降的 ShardingSphere-Proxy

记一次 JVM 参数调整导致 ShardingSphere-Proxy 性能下降的问题排查过程_第2张图片

性能正常的 Proxy 进程 JVM User 使用率更低,JVM System 更高;性能异常的 Proxy 进程 JVM User 使用率略高,JVM System 略低。
这个现象和上一节火焰图对比差异能够对应上,看起来性能异常的 Proxy 在 ShardingSphere 的计算逻辑上 CPU 消耗更多。

但这还不能确定性能问题的原因,还需要更多信息。

从 Java 进程启动时的 Warning 信息中发现端倪

在同一个环境下,分别对两个 ShardingSphere-Proxy 执行 start.sh -v 查看版本时,发现其中一个 Proxy 的脚本执行后 JVM 给出了两行警告信息,另一个 Proxy 却没有警告信息。

+ /tmp/shardingsphere-proxy/bin/start.sh -v
/usr/local/openjdk-17/bin/java
we find java version: java17, full_version=17.0.2, full_path=/usr/local/openjdk-17/bin/java
OpenJDK 64-Bit Server VM warning: UseNUMA is not fully compatible with SHM/HugeTLBFS large pages, disabling adaptive resizing (-XX:-UseAdaptiveSizePolicy -XX:-UseAdaptiveNUMAChunkSizing)
OpenJDK 64-Bit Server VM warning: Failed to reserve and commit memory. req_addr: 0x0000000400000000 bytes: 17179869184 page size: 2097152 (errno = 12).
ShardingSphere-5.3.3-SNAPSHOT
Branch: master

注意:虽然 Proxy 启动参数指定了 -XX:LargePageSizeInBytes=128m,但如果没有直接指定或间接(AggressiveHeap)指定 -XX:+UseLargePages,实际上没有效果。

https://github.com/openjdk/jdk17u-dev/blob/9b895233315c21920edc7ba48915afdc0a5c220a/src/hotspot/os/linux/os_linux.cpp#L3843-L3849
记一次 JVM 参数调整导致 ShardingSphere-Proxy 性能下降的问题排查过程_第3张图片

查看两个 Proxy 的 JVM 参数,发现参数唯一差异在于,性能正常的 Proxy 指定了 -XX:+AggressiveHeap,而性能较差的没有。
记一次 JVM 参数调整导致 ShardingSphere-Proxy 性能下降的问题排查过程_第4张图片

记一次 JVM 参数调整导致 ShardingSphere-Proxy 性能下降的问题排查过程_第5张图片

给性能较差的 Proxy 加上 -XX:+AggressiveHeap 并重新测试性能后,发现性能恢复到正常水平。

JVM 参数 AggressiveHeap 原理是什么?

ShardingSphere-Proxy 启用了 AggressiveHeap

ShardingSphere-Proxy 的启动脚本 start.sh 会根据使用的 JRE 版本,适当增加可以提升性能的参数。笔者曾经在 start.sh 中增加了一些适用于 Java 11 和 Java 17 的 JVM 参数以提高 ShardingSphere-Proxy 的性能,其中有一项就是 -XX:+AggressiveHeap

https://github.com/apache/shardingsphere/pull/15117

记一次 JVM 参数调整导致 ShardingSphere-Proxy 性能下降的问题排查过程_第6张图片

AggressiveHeap 是什么?

AggressiveHeap 这个参数比较冷门,能够搜到的资料非常有限,且搜索结果基本没有解释这个参数原理,而且有些博客对这个参数的理解存在偏差。

AggressiveHeap 是从 JDK 10 引入的一个参数,参数的解释就一句话:

Optimize heap options for long-running memory intensive apps

https://github.com/openjdk/jdk17u-dev/blob/9b895233315c21920edc7ba48915afdc0a5c220a/src/hotspot/share/gc/shared/gc_globals.hpp#L303-L304

在这里插入图片描述

这要如何理解?

解读 JDK 17 AggressiveHeap 源码

文档没说清楚,看源码是理解这个参数最直观准确的方式。

https://github.com/openjdk/jdk17u-dev/blob/9b895233315c21920edc7ba48915afdc0a5c220a/src/hotspot/share/runtime/arguments.cpp#L1789-L1895

源码较长,本文中不贴出。
总结一下,启用 AggressiveHeap 实际上不对应某一个具体的能力,而是让 JVM 自动设置一组 JVM 参数,大致如下:

  • 如果没有指定 -Xmx,则指定并固定堆内存大小为 Min(物理内存 / 2, 物理内存 - 160 MB)
  • 如果没有指定新生代比例,则设置 -XX:NewSize=堆内存的 3/8 -XX:MaxNewSize=堆内存的 3/8
  • 非 BSD 和 AIX 环境下,则启用 -XX:+UseLargePages
  • -XX:BaseFootPrintEstimate=堆内存大小,这个参数看起来和 ParallelGC 有关,笔者尚未进一步研究;
  • 固定 TLAB 空间为 256 KB -XX:TLABSize=262144 -XX:-ResizeTLAB
  • -XX:YoungPLABSize=262144(默认 8192);
  • -XX:OldPLABSize=8192(默认 1024);
  • 自 JDK 9 起,默认的 GC 为 G1,但 AggressiveHeap 会使用 ParallelGC -XX:+UseParallelGC
  • -XX:ThresholdTolerance=100(默认值 10),可能与回收频率控制有关,笔者尚未进一步研究;
  • 禁用 Full GC 前对新生代执行回收 -XX:-ScavengeBeforeFullGC

总结

为什么其中一个 Proxy 移除了 AggressiveHeap?

笔者询问了 Proxy 移除 AggressiveHeap 的原因,大致如下:

  • 目前 ShardingSphere-Proxy 在容器环境下(环境变量 IS_DOCKER 不为空),会不指定 -Xmx -Xms -Xmn 等指定堆内存的参数,而是使用百分比的方式指定内存使用。 -XX:InitialRAMPercentage=80.0 -XX:MinRAMPercentage=80.0 -XX:MaxRAMPercentage=80.0
  • 在实际容器环境中部署发现:使用 ShardingSphere-Proxy 镜像,容器可用内存 16GB,但 JVM 进程的堆内存只有 8GB,与参数指定的 80% 相差较大。移除 AggressiveHeap 后,JVM 堆内存接近可用内存 80%。

https://github.com/apache/shardingsphere/blob/b483b4ca96a87012ed12bc398fa34db35ef7ab11/distribution/proxy/src/main/resources/bin/start.sh#L78-L82
在这里插入图片描述
AggressiveHeap 仅考虑了是否指定了堆内存的具体大小,通过 MaxRAMPercentage 指定内存使用百分比不在 AggressiveHeap 的考虑范围之内,因此,AggressiveHeap 的逻辑会覆盖 MaxRAMPercentage 指定的上限。

琐碎想法

笔者认为,通过百分比设置 ShardingSphere-Proxy 的内存不是一个非常稳妥的办法。笔者曾经接触过部署在 Kubernetes 上的一些 Java 项目是通过环境变量设置 JVM 参数,指定明确的堆内存大小也许是个更合适的方式。

你可能感兴趣的:(性能,Apache,ShardingSphere,Java,jvm,性能优化,java)