龙空技术网

数据库调优-连接池优化

程序那点事 354

前言:

目前朋友们对“mysql连接数不够”都比较关怀,姐妹们都需要学习一些“mysql连接数不够”的相关资讯。那么小编也在网上搜集了一些有关“mysql连接数不够””的相关资讯,希望同学们能喜欢,朋友们一起来了解一下吧!

1.写在前面

在昨天的时候,我们就谈到了数据库调优原理和分享了JMeter数据库压力测试案例

详情可参考这里:点击查看

经过昨天的分析,我们已经基本掌握了如何通过JMeter压测工具,对mysql数据库进行压力测试。

那我们今天继续往下进行测试:连接池优化

说到连接池优化,可能大部分人都是比较蒙,毕竟在开发的过程中,也是很少关注过这一块配置。

哈哈,基于实际的情况,要想成为一个大牛,对数据库的优化,我们还是得多多少少掌握一点的。

那废话不多说,直接上!!!

首先,先贴下连接池的相关配置:

连接池参数配置:

字段

含义

Max Number of Connections

最大连接数;做性能测试时,可以填 0 。在开发的项目中按实际代码填写,默认是 20 。

Max Wait(ms)

在连接池中取回连接最大等待时间,单位毫秒

Time Between Eviction Runs(ms)

线程可空闲时间,单位毫秒如果当前连接池中某个连接在空闲了 time Between Eviction Runs Millis 时间后任然没有使用,则被物理性地关闭掉

Auto Commit

自动提交sql语句,如:修改数据库时,自动 commit

Transaction isolation

事务隔离级别

Preinit Pool

立即初始化连接池如果为 False,则第一个 JDBC 请求的响应时间会较长,因为包含了连接池建立的时间

Transaction Isolation: 事务间隔级别设置,主要有如下几个选项:(对JMX加解密)TRANSACTION_NODE 事务节点TRANSACTION_READ_UNCOMMITTED 事务未提交读TRANSACTION_READ_COMMITTED 事务已提交读TRANSACTION_SERIALIZABLE 事务序列化DEFAULT 默认TRANSACTION_REPEATABLE_READ 事务重复读、

看到这,有些小伙伴,可能要溜了,别慌,且听我一一道来!!!上干货,安排。。。

2.连接池优化

加不加连接池,对当前服务性能产生什么影响?

单个服务也会耗尽连接?

会不会对性能产生影响呢?会扣 1 , 不会扣 2 , 性能会变好扣 3 最大连接数越大是不是性能越好呢? 获取池中连接的最大等待时长?等待时间越短越好呢?

2.1JMeter优化

看到这里,是不是有点眼熟?

就是刚贴的,连接池参数配置

这里我们先对JMeter进行优化下,字体和外观。

切换到中文

找到jmeter.properties文件,添加下面配置:

language=zh_CN

然后重启下JMeter即可。

外观,有黑色改成白色2.2 不使用连接池

有什么问题呢?会报错

如果你不是多个应用程序同时连接MySQL,问题不大。但是如果你是多个应用程序连接数据库。 每个应用并发去获取数据库连接,会导致连接耗尽,资源争抢冲突!

这里,我们创建一个计划,去测试下:

线程数: 20

ramp-up: 1

循环次数: 2000

执行,查看结果树

可以看到,当不使用线程池时,很快,就报下面这个错了:

Response message:java.sql.SQLException: Cannot create PoolableConnectionFactory (Data source rejected establishment of connection, message from server: "Too many connections")
查看聚会报告2.3 连接池参数设置

压力测试连接池参数设置:

2.3.1 MaxWait

参数表示从连接池获取连接的超时等待时间,单位毫秒。

注意:这个参数只管理获取连接的超时。获取连接等待的直接原因池子里没有可用连接,具体包括如下四种情况:

连接池未初始化连接长久未使用已被释放,连接使用中需要新建连接连接池已耗尽需等待连接用完后归还

这里有一个很关键的点是 maxWait 未配置或者配置为 0 时,表示不设等待超时时间。也就是无限制等待

如果不配置maxWait,后果会怎么样呢?可能有些应用就这么干,来做个案例:

maxWait=0,maxActive=5,

对应JMeter的配置如下:

正常流量下业务没有发现任何问题,但突发大流量涌入时,造成连接池耗尽,所有新增的DB请求处于等待获取连接的状态中。

由于 maxWait=0 表示无限等待,在请求速度大于处理速度的情况下等待队列会越排越长,最终业务上的表现就是业务接口大量超时,流量越大造成实际吞吐量反而越低。

线程数 5 :

异常率:38%

线程数 10 :

异常率:50%

线程数 20 :

异常率:62%

由上可见,很明显,随着线程数增加,异常率不断增加。

配置建议:如果在内网,网络情况良好的情况下,maxWait应该设置为 800 毫秒。如果在外网,网络状况不佳值可以设置为 1200 毫秒。TCP重连的时间是 1 秒。

如果MaxWait值很大,会出现高并发情况下,获取不到连接,响应时间变长,吞吐量下降如果Maxwait值很小,会出现吞吐量奇高,但是异常数也奇高。

重点了,兄弟们。

maxWait,配置,get!!!

2.3.2 MaxActive

线程数: 20ramp-up: 1循环次数: 2000

最大连接池数量,允许的最大同时使用中的连接数。

注意:配置 maxActive 千万不要好大喜多,虽然配置大了看起来业务流量飙升后还能处理更多的请求,但切换到DB视角会发现其实连接数的增多在很多场景下反而会减低吞吐量,一个非常典型的例子就秒杀,在更新热点数据时DB 需要加锁操作,这个时候再让更多的连接操作DB就有点像假日往高速上涌入的车辆,只会给DB添堵。

最大连接: 10

最大连接数: 20

最大连接数: 30

配置建议:大多数场景下,配置 20 即可,足够使用的!建议结合实际业务场景设置,在业务系统稳定运行一段时间之后,获取稳定连接数,在这个基础之上乘以3-4即可!

为什么最大连接数设置的过多并不是一件好事? 是不是设置的连接数越多,性能就越好呢?不是!

首先,数据库的连接是非常宝贵的资源,很有限?数据库的最大连接数是多少? 151 个其次, 20 个连接足以支持到足够的TPS再次,如果设置最大的连接数过多了,会造成资源争抢。从而出现服务器报错!设置连接过多,没有提升性能反而性能下降在绝大多数业务场景下, 10 、 20 、 30 都足以支撑!

哈哈,这个参数,很重要喔,不记下来嘛?

# 查看数据库最大支持的连接数SHOW variables like 'max_connections';  //151# 查看数据库最大使用的连接数SHOW variables like 'max_user_connections';  //0
2.4 连接属性设置

之前在配置JDBC的连接池的时候讲过两个参数:serverTimezone=UTC&characterEncoding=utf-8。

接下来再说两个参数在网络方面有很大作用;主要应对在网络异常模式下,数据库无法释放连接的问题;

connectTimeout: 表示等待和MySQL数据库建立socket链接的超时时间。如果与服务器(这里指数据库)请求建立连接的时间超过ConnectionTimeOut,就会抛连接超时异常,即服务器连接超时。socketTimeout: 表示客户端和MySQL数据库建立socket后,读写socket时的等待的超时时间如果与服务器连接成功,就开始数据传输了。如果服务器处理数据用时过长,超过了SocketTimeOut,就会抛出SocketTimeOutExceptin,即服务器响应超时,服务器没有在规定的时间内返回给客户端数据。

jdbc:mysql://localhost:3306/dbname?serverTimezone=UTC&characterEncoding=utf-8&connectionTimeout=3000&socketTimeout=1200

解释:

一个请求包含三个过程:1.建立连接,2,数据传输,3.断开连接connectTimeout默认值 0 ,你连接超时。socketTimeout默认值,采用Linux操作系统的配置,默认值 30 分钟。

建议配置:connectTimeout 3000,socketTimeout 1200

哈哈,这里还是直接mark下吧!!!

好了,以上就是我个人的实操了。

个人理解,可能也不够全面,班门弄斧了。

好了,今天就先到这里了!!!^_^

后面的分享,就留在下次了,掰掰。

作者:llsydn

链接:

标签: #mysql连接数不够 #连接池参数