Spring Batch迁移Azure Kubernetes后性能下降，如何用IntelliJ分析调优？

• 先使用和生产一致的测试数据集复现问题，若需剖析AKS上运行的远程进程，先给Java启动参数添加JMX远程配置：

  -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=<Pod可访问IP>
  

  建议在测试环境复现问题后再做剖析，避免在生产环境附加Profiler影响业务
• 打开IntelliJ的 Profiler 工具，可从底部工具栏或顶部Run > Profiler菜单进入，选择附加本地进程，或选择「Remote JVM Profiler」填入AKS Pod的IP和JMX端口建立连接。
• 启动剖析会话时优先选择CPU采样模式，避免全量追踪的探针开销干扰真实性能表现，等批处理任务至少跑完10%的记录量后停止采样，保证样本有代表性。
• 采样结束后查看火焰图，重点关注CPU耗时Top10的方法：如果IO相关方法（数据库读写、网络调用、文件读写）占比极高，说明瓶颈在外部交互；如果业务计算方法占比过高，顺着调用链排查是否存在冗余序列化、反射调用、循环重复计算等问题。
• 同步开启内存剖析，查看堆内存占用和GC频次：如果Full GC频次超过10分钟1次，或单次Full GC耗时超过1秒，说明存在JVM内存分配不合理或内存泄漏问题。
• 配合IntelliJ数据库剖析工具，关联应用使用的数据源，采集批处理全流程的SQL执行日志，定位是否存在慢SQL、重复执行的无效SQL。

• 对比VM和AKS的基础资源配置：核对CPU核数、内存大小、磁盘规格/IO性能、网络带宽，若AKS节点使用低规格云盘，或者和依赖服务不在同一可用区，会直接拖慢整体处理速度。
• 对比JVM启动参数：确认AKS环境的Java参数和原VM配置一致，重点核对堆内存-Xmx/-Xms、垃圾回收器类型、新生代老生代比例，若AKS默认使用Serial GC而原VM用G1 GC，会出现数倍的性能差距。
• 排查外部依赖访问延迟：分别测试VM和AKS环境访问数据库、对象存储、第三方接口的平均延迟，很多时候AKS的网络策略、跨可用区访问会导致单次IO延迟翻数倍，累计后直接拉长批处理总时长。
• 检查K8s Pod运行状态：用kubectl top pod <Pod名称>查看运行过程中CPU、内存是否达到资源限制被限流（throttling），如果CPU限制设置过小，应用会频繁被内核调度限流，执行时长大幅上涨。
• 开启Spring Batch自带指标：在配置文件中设置spring.batch.jdbc.enable-metrics=true，输出每个Step、每个Chunk的处理耗时，直接定位是读、处理、写哪个阶段出现性能下降。
• 分阶段压测验证：将批处理的读数据、业务处理、写结果三个阶段拆分，单独压测每个阶段的吞吐量，快速缩小瓶颈范围。
• 排查系统底层指标：用iostat、vmstat、netstat等工具分别查看VM和AKS节点的磁盘IO使用率、上下文切换频次、网络重传率，确认是否存在磁盘满载、内核调度开销过高、网络丢包等底层问题。

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