一次服务端性能问题排查过程

陆续聊了性能测试指标和性能测试排查过程也有四五篇文章了，今天分享一个真实的性能测试真案例。

在一次某银行项目性能测试中，当系统运行到1个小时10分左右：tps出现明显下降,响应时间明显上升，其他相关业务cpu、内存、网络等各项指标都正常；此问题一直重复出现，而且在银行测试环境和公司测试环境一直存在。

通过分析怀疑可能是以下原因造成的

1.定时任务，

2.测试代码，

3.业务代码，

4.FGC。

然后就根据猜想一项一项测试验证。

1.停掉所有定时任务，和开发确认没有段时间插入定时日志或者其他数据库操作。

2.检查测试代码，测试代码和正确的测试代码只有很少的几行差异，而且全部是http连接规范的写法，不至于有问题。

3.业务代码，检查所有业务日志，tomcat日志，jstack抓trace等，都未见异常。

4. Full GC 通过抓jstat信息，发现在50分左右确实出现fgc如图：

full GC

但在相同时间，该接口的TPS有少量下降， 不是原来遇到的大量下降，如图

故排除fgc问题。貌似再次测试进入死胡同，再次怀疑此应用代码问题。

就在早上突然想到是不是负载均衡工具有问题？？？？到公司迫不及待的测试下。

通过测试，去掉负载haproxy代理，自己写了一个随机分配到四个应用节点地址，通过三个小时测试，没有出现上述怪异的问题。

告诫各位，在性能测试时，特别要小心软负载工具的应用，对性能测试的影响， haproxy工具坑我好几次了，使用时一定要小心。

2019年连续第五十八天修心 土司于北京

如果你喜欢我的文章，欢迎关注扫描公众账号：MiniStarClub