---
title: 使用DevKit自动调优KAT工具和java-perf工具调优案例-官方技术文章-鲲鹏社区
description: 使用DevKit自动调优KAT工具和java-perf工具调优案例
keywords: DevKit,KAT,自动调优,工具和,工具调优案例,官方技术文章,鲲鹏社区,介绍
url: https://www.hikunpeng.com/developer/techArticles/20251205-5?envFlag=1
section: (其他)
---

# 使用DevKit自动调优KAT工具和java-perf工具调优案例-官方技术文章-鲲鹏社区

URL: https://www.hikunpeng.com/developer/techArticles/20251205-5?envFlag=1
描述: 使用DevKit自动调优KAT工具和java-perf工具调优案例
关键词: DevKit,KAT,自动调优,工具和,工具调优案例,官方技术文章,鲲鹏社区,介绍

官方技术文章 [了解详情](https://www.hikunpeng.com/zh/developer/techArticles)

使用DevKit自动调优KAT工具和java-perf工具调优案例

使用DevKit自动调优KAT工具和java-perf工具调优案例

性能调优同辕开发

发表于 2025/12/05

0

## 一、介绍

用户在鲲鹏服务器上运行业务时，发现存在较大的性能瓶颈，现象为：

压测流量超过某固定阈值x时，会存在较大的服务延迟；超过更大的阈值y时，会存在CPU占满和OOM事件，导致丢包，严重影响业务的正常运行。

在对业务场景不熟悉，而业务存在明显调优瓶颈时，可以先用KAT自动调优工具进行尝试，它集成了诸多如system参数、数据库业务参数、jvm参数等调优手段，通过黑盒调优的方式，通过回归迭代寻优找到当前系统上，符合当前业务运行的最优参数空间。KAT工具的使用和安装详见https://www.hikunpeng.com/document/detail/zh/kunpengdevps/userguide/cliuserguide/KunpengDevKitCli_0089.html [了解详情](https://www.hikunpeng.com/document/detail/zh/kunpengdevps/userguide/cliuserguide/KunpengDevKitCli_0089.html)

## 二、基线测试

由于业务中使用的中间件为kafka，并且使用了java相关服务，因此考虑使用KAT的sys/kafka/jvm这三组参数空间，并根据业务的实际情况进行简单的适配，以符合每轮测试的完整流程，KAT稳定测试流程包括：服务重启（保证每次测试环境的一致性）->服务warm up(让系统达到稳定状态)->执行压测->结果统计->环境清理。按照该流程，填写好KAT的task模板后，执行基线的测试。

而在执行基线测试后，发现延迟阈值x和丢包阈值y相比之前提高了50%，通过前后流程对比，发现为warm up所致，这说明之前的测试方式存在问题，系统尚未达到稳定状态时进行压测导致硬件的能力尚未完全发挥。

最终KAT工具调优基线为：在流量M下，进行N次数据包回放的总处理时间作为性能指标，在不丢包的情况下，该值越低，说明业务被延迟处理的时间越小，越接近最优性能。

## 三、训练调优

在自动训练80轮后的结果如下所示，从基线的491s优化到308s，提升59%，在复测后证实有效，且发包总时间为230s，从延迟时间的角度来看，已经从261s优化至78s，提升70%

## 四、使用java-perf进行原理分析

为了探寻warm up策略以及KAT调优后的参数空间对于业务的实际影响情况，通过java-perf进行深入的性能分析，java-perf的使用方式见https://www.hikunpeng.com/document/detail/zh/kunpengdevps/userguide/usermanual/devkit-hypertuner-097.html [了解详情](https://www.hikunpeng.com/document/detail/zh/kunpengdevps/userguide/usermanual/devkit-hypertuner-097.html)

调优前：

warm up策略+KAT调优

通过对比GC日志，很明显发现在调优前的GC吞吐量、堆使用情况并不合理：

1、单次GC时间过长，为调优后平均GC时长10倍

2、平均GC频率高，是调优后平均GC频率5倍

3、总GC时长为调优后总GC时长120倍

此外，调优前在压测过程中，会存在堆中eden区大小持续波动，最后稳定在过高水平，从结果反推，应该调大jvm参数中eden区的比例，如下：

-XX:+UnlockExperimentalVMOptions (解锁实验性jvm选项)

-XX:G1MaxNewSizePercent=60（最大年轻代堆内存百分比）

-XX:-G1UseAdaptiveIHOP（并发标记动态调整）

-XX:InitiatingHeapOccupancyPercent=25(设置G1开始并发标记周期的堆占用率阈值)

加入以上参数再进行复测，针对GC情况再进行统计：

修改前

修改后

延迟从260s→35s,总时长492s→270s，提升82.22%！

## 五、总结

本案例针对业务运行过程中的性能问题进行解决定位，首先使用KAT工具进行黑盒调优，warm up策略提升延迟阈值/丢包阈值50%，自动训练后延迟提升70%，而后进行java-perf根因分析，进一步定位到GC问题，针对性修改GC参数后，最终延迟时长提升82.22%。

本页内容