性能测试：数据库连接池问题分析

前言
今天我们来压测一个支付的接口，10个并发，压测5分钟。下面我们可以看到tps大概在200多，响应时间在40ms左右。
下面我们来看一下服务器的性能，应用服务器的cpu使用率大概在60%左右。再来看一下数据库服务器，数据库服务器的性能还算正常，cpu使用率大概在25%左右，而且我们支付的接口，还是在做一个写库的操作，下单的时候，会往订单表中插入数据。并且我们不断加压，新增并发，cpu仍然没有大概100%，tps也没有新增，响应时间整体越来越长。通常这种现象我们应该怎么排查呢？

可以从下面两方面来排查：

• 查看具体程序中哪个函数对于cpu的消耗是较高的
• 关注线程情况

下面我们使用 jprofiler ，我们来看一下hotspots，前两个主要是关于jdk和tomcat底层的，我们可以不用管，下面这个是关于数据库相关的操作，因为我们现在压测的接口，会涉及到写库的操作，所以他会对我们的sql进行编译。那么我们从这个角度来看，这个对与cpu的消耗都是正常的，主要是对sql的执行和编译。

下面我们再来看一下GVM。主要是看内存，内存这一块想对还是平稳的，没有看出有内存溢出的趋势。

GC 的话，也没有看出太多的异常。

我们再来看看线程，里面可以看到有一些线程存在阻塞的现象。但是阻塞时间想对来说比较短暂，我们可以先做一个堆栈信息的打印查看一下具体的情况。
我们使用如下命令，打印堆栈信息：

1｜jstact pid >test.log   // pid 为tomcat的进程id

在堆栈信息中，我们可以看到文件中，有大量线程都处于TIME_WATING的状态。
我们这里可以看到有一个关键字 druid，这个是数据库的连接池，我们可以看到有大量的连接池处于等待的状态。
下面我们来查看数据库最大连接数：

1｜show variables like '%connections%';

我们可以看到数据库最大连接数默认情况下，是151；这个值我们可以进行修改，但是一般通常情况下不建议修改的太大，一般公司通常是配置在800-1000；因为数据库本身不适合搞太大的连接数，前面我们才10个并发，5个并发数，cpu就已经被压的非常高了。查看当前和数据库建立的连接数：

1｜show status like '%thread%';

1. Threads_cached：线程缓存内的线程数量
2. Threads_connected：当前打开的连接数量
3. Threads_created：创建的线程数
4. Threads_running：

我们可以看到上方的数据，当前建立的连接数只有Threads_connected 6个。而我们最大的连接数默认有151个，那就说明并没有达到最大值，说明是我们连接池的问题。

下面我们再来看一下连接池的配置，可以看到我们最大活动连接数只有5个，这个有点低，这里改成50，一般建议不要设置太大。修改了配置文件之后，需要重启tomcat。

下面是关于数据库连接池配置的一些建议：

• initialSize：对于 db 规模不是特别大的情况下可考虑设置为 1-5个。避免启动时间过长，以及没有业务时占用过多的数据库连接资源
• minIdle：可考虑该值的设置和初始化连接保持一致；
• maxActive 最大连接不要设置过大，避免本地维护的 db 太大。 如果对应到数据源的并发数过高，可考虑增大最大连接数。一般设置
  20-50 比较合理
• maxWait：获取连接的超时时间：如果连接全部被占用，需要等待的时间。可以根据当前系统的响应时间判定，如果容忍度较高，可以大点。容忍度较低，设置小点。一般设置
  5000-10000

那么我们修改配置之后，再来进行压测。可以看到tps大概在900左右，响应时间在15ms左右。

我们可以使用如下命令查看端口的使用情况。

1｜netstat -anp | grep 3306 | grep  114.55.34.236 | wc -l