性能问题分析调优案例第16篇
案例背景
压测业务：某接口
压测工具：Jmeter
场景设置：100秒内逐步加压20个并发线程，场景总时长5分钟
压测环境：linux + tomcat 8.5
问题描述：随着并发压力的增加，TPS保持不变，此时服务器的各项资源指标未达到饱和状态
从上图可以看出，虽然此次压测只用了20并发，但是当并发线程达到10个左右时，TPS几乎就已经持平了
平均响应时间图
分析过程
首先，先看下系统的硬件资源
应用服务器CPU使用率
数据库服务器CPU使用率
总体上应用和数据库服务器的各项资源都还处于正常水平，包括CPU、内存、IO、网络等等。
接着，查看数据库的TOP SQL，也没发现可疑的目标，而且一般数据库TOP SQL有问题的话，在数据库的CPU和IO使用率上也会体现出来。
到这里，还未查到什么可疑的问题。
一般，如果硬件资源、网络和带宽、数据库TOP SQL都找不到问题的话，那么就应该查查应用服务了。
在TPS达到瓶颈后，通过jstack得到线程快照，多打几次。
分析线程快照，发现业务线程中有一半处于运行中状态（主要是等待数据库返回结果），但是还有一半处于以下状态：
这些线程在等待取得数据库连接。。。
本压测场景只用了20并发，数据库连接池配置max Active=50，怎么还会有这么多线程在等待数据库连接？
莫非是数据库连接池配置没有生效？
于是，从其他方面再次进行验证，比如操作系统层面通过如下命令
可以看到该服务进程和数据库之间的连接数确实只有8个。
跟开发了解得知，此服务用的数据库连接池是dbcp2，上网搜索资料，发现它的默认最大连接数确实就是8个。
但是配置文件可以肯定已经将它调整为50了，为什么它最大还是只有8个？
继续搜索相关资料，有人提到由于commons-dbcp所用的连接池出现版本升级，因此commons-dbcp2中的数据库池连接配置也发生了变化，具体的参数配置说明如下：
可以看到新版本的最大连接数配置参数已经由maxActive改成maxTotal了，真是坑啊~
于是让开发调整这个配置项参数，问题解决。
总结
- 遇到系统TPS上不去的时候，可以通过看线程信息和其他手段（如服务进程到数据库的连接数）确认是否数据库连接池数瓶颈导致；
- 很多公司的架构和开发人员，在配置一些系统关键参数时，往往都是从网上CTRL+C得来，但是这些配置信息随着版本的迭代更新，其实可能已经过时了，导致这些关键参数配置并未生效，而使得系统存在性能隐患；
