1. 问题描述
后台服务班次转换通过定时任务，每五分钟执行一次，每日1000班次，要跑将近4，5小时，平均下来1分钟仅能跑几个班次。单个班次执行约20-30s。班次转换速率严重滞后，月底重跑多天报表，可能严重拖慢报表生成进度。
2. 问题定位及分析
2.1. 服务器负载分析
定时任务跑批次期间，通过top命令查看服务负载情况，CPU负载仅23.3%，内存负载13.2GB约56%，并不存在瓶颈情况。
2.2. JVM负载分析
使用Arthas工具（dashboard），查看cms服务班次跑批期间的jvm负载情况，具体情况如下： （备注：原默认垃圾回收器ps_survivor占用98%，切换g1gc，由jvm自行分配eden和s区的大小，以及对象晋升的次数） Heap情况:
- 总堆内存: 12GB (12288M)
- 已使用: 3.8GB (3949M) - 32.14% 使用率
- 年轻代: 3.6GB (3668M) - 占堆的 47.74%
- 老年代: 221M - 仅占堆的 1.80%
Gc情况：
- 年轻代GC次数: 65次，时间1700ms
- 老年带GC次数0
根据Arthas工具dashboard实时打印的结果，JVM的总体负载不高，不存在瓶颈情况。
2.3. 关键代码执行时间分析
使用Arthas工具对定时任务代码分析：
-
trace com.hkl.pos.service.impl.AtsConvertServiceImpl convertSuccessionByLock
以下捞出关键的几种类型：
以上截图trace结果可以得出结论：
- 大量耗时存在于班次的转换的方法内；
- 约一半的方法执行失败，获取jdbc连接超时；
- trace因为性能关系只统计一个层架，需要往下再定位详细方法的执行耗时；
-
trace -E com.hkl.pos.service.impl.AtsConvertServiceImpl convertSuccessionByLock|convertSuccession|convertOrder -n 1000
以上trace结果可以得出结论：主要执行耗时代码在ats_bb表执行插入数据耗时过长；
2.4. 数据库入库慢定位
定位bb表插入慢的主要原因：
1. 数据量过大或者索引过多，锁或者外键，触发器导致插入慢；
2. 插入数据需要写数据文件、redo日志文件、undo表空间配置问题导致插入慢；
3. 优化方案与结果
3.1. 单个任务优化
3.1.1. 历史数据归档
bb表历史数据先归档处理，大大提升入库时间。
3.1.2. JDBC连接池优化
3.1.3. 长事务周期优化
将大事务拆分成小事务，查询和转换方法执行后，再进行数据库事务操作，防止大事务长时间持有占用JDBC连接。具体操作如下：
3.1.4. 优化效果
耗时统计
3.2. 引入分布式中间件（后续安排）
后续走直接生成，暂不需要进一步优化......
1. 总结
- 增加数据库连接数的最大连接池个数，是最直接的问题的方式。解决大量jdbc连接获取失败问题；
- 历史数据归档，大大降低数据库入库和删除时间；
- 限制每个定时任务跑固定个数（当前每5分钟定时任务500条班次任务->约每天的班次要10分钟）
- 拆分大事务，防止长时间占用jdbc连接；
- 排查定位：使用阿里开源工具Arthas，可以快速定位问题和瓶颈，且上手快。
