记一次 Java 应用性能问题定位

问题

系统大部分时间响应速度正常（平均响应时长在 50 - 500 ms)，但近期隔一段时间，前端请求频发卡顿、请求超时的问题，但是一会就又好了；虽然能用，但这对于程序员来说是不能忍的，必须揪出的问题，搞定它；

当前服务现状

服务是一个基于 Java 生态圈开发的工作流调度系统，主要由两个部分组成（耦合在一起了）

• 内嵌的 Jetty server + spring web 服务： restfull api 的方式提供工作流管理服务，系统的权限认证外接的 Iam sdk；
• 基于 quartz 的 DAG 工作流调度模块：提供 DAG 任务调度流转服务；

由两台 server 以双主的方式提供服务，server 使用的组件包括

• mysql 使用阿里的 Druid 连接池
• redis 集群
• rockemq
• zookeeper

定位过程

定位点

• JVM GC 问题
• mysql 数据库瓶颈，大表，复杂查询
• 线程阻塞、死锁
• 服务器资源 cpu 内存 io 瓶颈

1. 查看 gc 日志，基本正常，除了一天服务器使用 Java 7 young gc 频繁了一些，后期需要优化；先排除 gc 的问题；
2. 联系 mysql dba，其反馈数据库监控显示无明显有规律的慢查询；此外，自己也手写脚本循环请求数据库访问，无任何异常，排除数据库的问题；
3. 看下线程栈是否正常，Jstack 是 java 性能问题定位神器，之前 hiveserver 定时挂的问题（todo）也是通过 jstack 定位到的，通过几次 jstack 发现线程基本正常，没有发现过多的线程，以及阻塞的线程；
4. top 监控显示，服务器的内存，cpu 都是够够的，排除；

全部排除了

定位问题 - 接口测试

首先通过一个简单的接口来测试定位问题： https://xxx/project/selectAllProjectList，此接口查询一张总行数为 8 的表，select * 操作；正常的响应时间在 50 ms 左右

编写脚本循环请求此接口接口，当响应时间超过 1s，打印响应时长；通过监控发现，服务器 10.167.6.29 上 在 15:30-15:31 发现响应速度骤降（100 倍），最长到 20 秒，整个卡顿时间持续1分钟，如下图：

image.png

通过日志量来判断请求是不是增多，grep count 这个时间段日志行数：

image.png

观察时间段是16:00，搜索统计，日志量环比猛增 50倍

image.png

进一步定位 pending ack 消息（消费）消费超过每秒 100+

通过mq admin 监控页面：

runningTopic 的消息量（发出的任务数）在16:00 处于波峰:

6.29 server 正常消费 日志量正常

image.png

image.png

image.png

16:00监控数据

image.png

16:30 监控数据

image.png

初步得出结论，但没定位到问题

1.server 消费大量消费, 性能下降，每分钟 238 条消息
2.6.28 日志量剧增，6.29 正常，说明 quartz 在两台机器拉起任务不均衡
6.28 消费与日志量统计

image.png

6.29 消费与日志量统计

image.png

16：00 启动的任务数 215 （大部分任务都配置了整点 0 点 0分 ，0分，30分，并发高）

image.png

发现问题 1

配置的定时任务都是在整点，mq 的监控数据也很有规律，整点在波峰，这点很关键
经过验证，在整点使用系统，必卡；

image.png

发现问题 2

6.28 16：00 启动了 205 个定时工作流 而 6.29 一共只有 13 个

经定位，多次 jstack grep 同一个卡主的线程 id ，发现在 iam filter 这里卡了 8 秒之多；至此可以初步断定，瓶颈在 IAM 系统；
需要注意的是：在定位问题的过程中，使用 jstack 我们更关注 waiting block 的线程，容易漏掉 running 的；

image.png

web.xml 配置了拦截器，rest请求，会先走 iam 过滤，判断用户是否登录

iam 拦截代码如下：

image.png

继续定位 IAM

既然发现是 IAM 瓶颈，在整点 jstack 日志，很快发现问题：
33个线程处于 waiting 阻塞等待中，

image.png

image.png

http://fisheuler.github.io/c3p0-debug.txt
c3p0 连接池的问题，服务器 c3p0 线程池配置都是默认值，maxSize 只有15 应该是不够的；

梳理下跟踪链：
调度系统前端请求偶发卡段
找到规律：整点卡顿
整点配置的定时任务最多
整点 jstack 发现 running 线程卡在 iam filter 拦截器
继续跟踪 iam ，整点 jstack 发现多数 mysql 线程 处于最等待状态
mysql 使用 c3p0 连接池，至此定位到是连接池问题

最终结论

• 1.整点任务量剧增，主要是定时任务量剧增，系统 restfull 接口性能严重下降；定位出瓶颈在 IAM 服务，在任务量剧增时，响应超长，超时；
• 2.两台 server 定时任务拉取不够均衡；具体原因待定位；

总结

• 搭建完善的可视化监控系统：包括接口响应时长监控，cpu 内存监控，gc 监控等；
• 熟练典型的性能定位工具：包括 jstack top free jstat 等
• 发现规律，总结规律：最好通过监控，图形化系统卡顿的时间曲线图，这样可以第一时间发现规律，避免大海捞阵，盲找的情况。
• 定点定位：在规律的时间点去监控系统指标，这样更有针对性，能更快的发现问题；