Spring Batch迁移AKS后性能下降，如何定位致问题的Java方法与SQL查询

第一步：先排除基础设施层面差异 #

• 核对AKS Pod的资源配额（CPU/内存/磁盘IO/网络带宽）是否和本地部署环境完全对齐，若Spring Batch存在大量临时文件落盘逻辑，优先确认AKS挂载磁盘的IOPS、吞吐量是否达标，可通过iostat、dstat命令分别在本地和AKS环境采样同作业阶段的资源使用率
• 核对数据库连接配置：AKS到数据库的网络延迟、连接池最大连接数、超时参数是否和本地一致，可通过ping、tcptrace测试同条件下的数据库往返延迟
• 排查AKS额外性能开销：确认是否有Sidecar代理（Istio/Linkerd）的流量拦截开销、Pod的QoS等级是否为Burstable/BestEffort导致被节点限流、是否开启了未适配的日志采集Agent占用大量CPU资源

第二步：拆分Spring Batch作业阶段耗时，缩小排查范围 #

• 直接读取Spring Batch自带元数据表BATCH_JOB_EXECUTION、BATCH_STEP_EXECUTION的统计数据，对比本地和AKS环境下每个Step的耗时，先定位到耗时翻倍的具体Step
• 对异常Step进一步拆分读（Reader）、处理（Processor）、写（Writer）三个阶段的耗时，可通过添加阶段埋点日志或者Profiler火焰图对比同阶段的耗时占比

第三步：定位异常Java方法 #

• 你正在使用的Profiler工具可直接复用，注意保持本地和AKS环境的采样时长、业务负载完全一致，避免采样偏差：
  • 优先对比两个环境的CPU采样火焰图，查看CPU占比Top10的方法，是否有方法在AKS环境下的占比远高于本地
  • 检查锁等待、IO等待的占比是否存在异常升高
  • 核对JVM参数是否对齐：包括GC算法、堆内存大小、新生代比例，可通过jstat -gcutil [pid] 1000采样两个环境的GC耗时和频率，若GC耗时占总运行时间超过10%需调整JVM参数

第四步：定位慢SQL查询 #

• 开启数据库慢查询日志，采集AKS环境下作业运行全周期的慢SQL，和本地环境的慢SQL做对比：
  • 若相同SQL在AKS环境执行耗时更高，优先排查网络延迟、数据库实例负载、索引是否缺失
  • 若SQL执行耗时相近但总调用次数翻倍，检查Spring Batch配置：比如chunk大小是否被错误修改、是否开启了不必要的状态查询、是否重复提交查询请求
• 配合Profiler的JDBC探针，直接关联Java方法调用和对应的SQL执行耗时，快速定位触发慢SQL的业务代码位置

第五步：验证排查结果 #

• 定位到异常方法或SQL后，单独对该逻辑做基准测试，分别在本地和AKS环境运行，验证耗时差异是否和全作业的耗时差异匹配
• 修复后先做小流量灰度验证，确认性能恢复到本地水平后再全量部署

内容的提问来源于stack exchange，提问作者One Developer