前言
今天我们来压测一个支付的接口,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%';
- Threads_cached:线程缓存内的线程数量
- Threads_connected:当前打开的连接数量
- Threads_created:创建的线程数
- 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