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

最新推荐文章于 2025-08-19 00:42:36 发布

原创

最新推荐文章于 2025-08-19 00:42:36 发布 · 878 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#jvm #性能优化 #java

文章详细描述了一次针对ShardingSphere-Proxy的性能测试过程，发现在更新版本后TPC-C场景下的性能下降约7%。通过async-profiler的火焰图分析，发现新版本在I/O和计算逻辑上的CPU使用有变化。进一步排查发现，性能下降与JVM的AggressiveHeap参数缺失有关，当添加该参数后，性能恢复正常。AggressiveHeap是一个优化长期运行、内存密集型应用的JVM参数，其具体作用包括堆内存设置、大型页面使用等。文章讨论了AggressiveHeap的原理，并指出在容器环境下，通过百分比设置内存可能导致的问题。

问题现象

在性能测试中，分别对两个版本差异间隔一天的 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

在这里插入图片描述

性能下降的 ShardingSphere-Proxy

在这里插入图片描述

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

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