您的位置:

关于linuxmysql连接池的信息

本文目录一览:

什么是mysql连接池,它的主要功能是什么

数据连接池是把数据库连接放到中间服务器上,比如tomcat上,那么相当于每次你操作数据库的时候就不需要再"连接"到数据库再进行相关操作,而是直接操作服务器上的"连接池",你可以根据字面意思进行理解,把数据库当做一条小溪,那么"连接池"就是一个"水池",这个水池里面的水是由事先架好的通向"小溪"的水管引进来的,所以,你想喝水的时候不必大老远地跑到小溪边上,而只要到这个水池就可以.这样的话就可以提高"效率".但是数据池一般是用在数据量比较大的项目,这样可以提高程序的效率,想一想这样的话是不是就把相关的负荷加在了服务器上,因为这个"池"是在服务器上的,对于小数据量处理的项目不推荐使用,应为过于频繁的请求会使得服务器负载加重

关系:

你 --"水池"--小溪(快速喝水)

程序--"数据池"--数据库(快速存取)

就是这样,也不用把它想神秘了,我是这样理解的,也就这样说了,希望对你有帮助

高并发的MySQL数据查询时,会不会选择数据库连接池?

现象

Sysbench对MySQL进行压测, 并发数过大(5k)时, Sysbench建立连接的步骤会超时.

猜想

猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.

验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.

检查环境

猜想失败, 回到常规的环境检查:

MySQL error log 未见异常.

syslog 未见异常.

tcpdump 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.

自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响

猜想2

怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:

检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.

通过strace检查MySQL, 发现 accept() 调用确实没有感知到新连接.

怀疑是OS的原因, Google之, 得到参考文档: A TCP “stuck” connection mystery【】

分析

参考文档中的现象跟目前的状况很类似, 简述如下:

正常的TCP连接流程:

Client 向 Server 发起连接请求, 发送SYN.

Server 预留连接资源, 向 Client 回复SYN-ACK.

Client 向 Server 回复ACK.

Server 收到 ACK, 连接建立.

在业务层上, Client和Server间进行通讯.

当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:

Client 向 Server 发起连接请求, 发送SYN.

Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.

Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).

Server 验证签名, 分配连接资源, 连接建立.

在业务层上, Client和Server间进行通讯.

当启用SYN-cookie时, 第3步的ACK包因为 某种原因 丢失, 那么:

从Client的视角, 连接已经建立.

从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)

发生这种情况时:

若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误

若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.

TCP握手的第三步ACK包为什么丢失

参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:

Some of these packets get lost because some buffer somewhere overflows.

我们可以通过Systemtap进一步探究原因. 通过一个简单的脚本:

probe kernel.function("cookie_v4_check").return

{

source_port = @cast($skb-head + $skb-transport_header, "struct tcphdr")-source

printf("source=%d, return=%d\n",readable_port(source_port), $return)

}

function readable_port(port) {

return (port ((19)-1)) 8 | (port 8)

}

观察结果, 可以确认cookie_v4_check (syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.

之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):

static inline bool sk_acceptq_is_full(const struct sock  *sk){   return sk-sk_ack_backlog sk-   sk_max_ack_backlog;}

恢复故障与日志的正关联

在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.

当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.

检查Linux源码:

if (!queue-synflood_warned

sysctl_tcp_syncookies != 2

xchg(queue-synflood_warned, 1) == 0)

pr_info("%s: Possible SYN flooding on port %d. %s.

Check SNMP counters.\n",

proto, ntohs(tcp_hdr(skb)-dest), msg);

可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.

粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.

解决方案

这种故障一旦形成, 难以检测; 系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制, 万劫不复.

解决方案:

1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.

2. 关闭syn_cookie. 有安全的人又要跳出来了.

3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.

有多个系统参数混合影响syn backlog长度, 参看【】

下图为精华总结

请点击输入图片描述

一般连接池是怎么处理mysql自动回收长时间

更快速的配置对比 pt-config-diff在我们日常工作中,大家一定遇到过以下场景:

若干套 MySQL 环境,只有一套:

∘ 行为异常,怀疑触发 bug

∘ 性能异常,比其他环境都要低

在这种场景下,我们一般的做法是首先控制变量,查看软硬件配置,以及 MySQL 的参数配置。关于 MySQL 的参数配置对比,如果我们人工对比的话只会关注某些重点参数,而缺少了整体细节上的的对比。在这里我们推荐给大家 Percona Toolkit 中的一个工具 pt-config-diff

更准确的复制延时 pt-heartbeat在 MySQL 中,复制延迟可以理解为由两部分组成:1. 主库已经生成了 BINLOG,但是还没有发送给从库 -- 我们在这里称之为:日志延迟2. 从库已经接收到了 BINLOG,但是还没有应用完成 -- 我们在这里称之为:应用延迟MySQL 原生的查看复制延迟的手段为:show slave status\G中的Seconds_Behind_Master。这种观测手法只能观测出应用延迟。在异步复制或降级的半同步复制下,误差较大,无法准确的反映出整体复制延时。

1. 在 Master 上循环插入:insert into database.heartbeat (master_now) values(NOW())

2. database.heartbeat 的变更会跟随主从复制流向从库

3. 系统当前时间 - 从库表中的时间 = 从库实际的复制延时

更简单的参数配置建议 pt-variable-advisortoolkit 中包含了一个简单的 MySQL 参数优化器,可以对参数配置做简单的优化建议。

更准确的复制延时 pt-heartbeat在 MySQL 中,复制延迟可以理解为由两部分组成:1. 主库已经生成了 BINLOG,但是还没有发送给从库 -- 我们在这里称之为:日志延迟2. 从库已经接收到了 BINLOG,但是还没有应用完成 -- 我们在这里称之为:应用延迟MySQL 原生的查看复制延迟的手段为:show slave status\G中的Seconds_Behind_Master。这种观测手法只能观测出应用延迟。在异步复制或降级的半同步复制下,误差较大,无法准确的反映出整体复制延时。

更易用的调试工具 pt-pmp在某些情况下,我们肯定会遇到某些故障无法从日志,以及状态命令中找到原因,需要深入到程序逻辑级别。又或者我们需要立即通过非常规手段恢复故障数据库,但是又想保留足够多的故障信息。来避免我们事后复现问题的头疼。pt-pmp 便是在这种场景下帮助我们的工具。它会使用 gdb 来打印 mysqld 的堆栈信息,并把调用链相同的线程堆栈合并。堆栈合并的功能对于 MySQL 这种多线程的应用非常有帮助,会节省我们大量的时间。

MySQL与Redis数据库连接池介绍(图示+源码+代码演示)

数据库连接池(Connection pooling)是程序启动时建立足够的数据库连接,并将这些连接组成一个连接池,由程序动态地对池中的连接进行申请,使用,释放。

简单的说:创建数据库连接是一个很耗时的操作,也容易对数据库造成安全隐患。所以,在程序初始化的时候,集中创建多个数据库连接,并把他们集中管理,供程序使用,可以保证较快的数据库读写速度,还更加安全可靠。

不使用数据库连接池

如果不使用数据库连接池,对于每一次SQL操作,都要走一遍下面完整的流程:

1.TCP建立连接的三次握手(客户端与 MySQL服务器的连接基于TCP协议)

2.MySQL认证的三次我收

3.真正的SQL执行

4.MySQL的关闭

5.TCP的四次握手关闭

可以看出来,为了执行一条SQL,需要进行大量的初始化与关闭操作

使用数据库连接池

如果使用数据库连接池,那么会 事先申请(初始化)好 相关的数据库连接,然后在之后的SQL操作中会复用这些数据库连接,操作结束之后数据库也不会断开连接,而是将数据库对象放回到数据库连接池中

资源重用:由于数据库连接得到重用,避免了频繁的创建、释放连接引起的性能开销,在减少系统消耗的基础上,另一方面也增进了系统运行环境的平稳性(减少内存碎片以及数据库临时进程/线程的数量)。

更快的系统响应速度:数据库连接池在初始化过程中,往往已经创建了若干数据库连接置于池中备用。 此时连接的初始化工作均已完成。对于业务请求处理而言,直接利用现有可用连接,避免了从数据库连接初始化和释放过程的开销,从而缩减了系统整体响应时间。

统一的连接管理,避免数据库连接泄露:在较为完备的数据库连接池实现中,可根据预先的连接占用超时设定,强制收回被占用连接。从而避免了常规数据库连接操作中可能出现的资源泄露。

如果说你的服务器CPU是4核i7的,连接池大小应该为((4*2)+1)=9

相关视频推荐

90分钟搞懂数据库连接池技术|linux后台开发

《tcp/ip详解卷一》: 150行代码拉开协议栈实现的篇章

学习地址:C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂

需要C/C++ Linux服务器架构师学习资料加qun 812855908 获取(资料包括 C/C++,Linux,golang技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg 等),免费分享

源码下载

下载方式:(Github中下载)

db_pool目录下有两个目录,mysql_pool目录为MySQL连接池代码,redis_pool为redis连接池代码

下面介绍mysql_pool

CDBConn解析

概念: 代表一个数据连接对象实例

相关成员:

m_pDBPool:该数据库连接对象所属的数据库连接池

构造函数: 绑定自己所属于哪个数据库连接池

Init()函数: 创建数据库连接句柄

CDBPool解析

概念:代表一个数据库连接池

相关成员:

Init()函数:常见指定数量的数据库实例句柄,然后添加到m_free_list中,供后面使用

GetDBConn()函数: 用于从空闲队列中返回可以使用的数据库连接句柄

RelDBConn()函数: 程序使用完该数据库句柄之后,将句柄放回到空闲队列中

测试之前,将代码中的数据库地址、端口、账号密码等改为自己的(代码中有好几处)

进入MySQL, 创建mysql_pool_test数据库

进入到mysql_pool目录下, 创建一个build目录并进入 :

然后输入如下的命令进行编译

之后就会在目录下生成如下的可执行文件

输入如下两条命令进行测试: 可以看到不使用数据库连接池,整个操作耗时4秒左右;使用连接池之后,整个操作耗时2秒左右,提升了一倍

源码下载

下面介绍redis_pool

测试

进入到redis_pool目录下, 创建一个build目录并进入 :

然后输入如下的命令进行编译

之后就会在目录下生成如下的可执行文件

输入如下的命令进行测试: 可以看到不使用数据库连接池,整个操作耗时182ms;使用连接池之后,整个操作耗时21ms,提升了很多

进入redis,可以看到我们新建的key:

MySql数据库连接池如何配置

连接先建立一些连接,并且这些连接允许共享,因此这样就节省了每次连接的时间开销。Mysql数据库为例,连接池在Tomcat中的配置与使用。

1、创建数据库Student,表student

2、配置server.xml文件。Tomcat安装目录下conf中server.xml文件。

GlobalNamingResources

Resource

name="jdbc/DBPool"

type="javax.sql.DataSource"

password=""

driverClassName="com.mysql.jdbc.Driver"

maxIdle="2"

maxWait="5000"

username="root"

url="jdbc:mysql://localhost:3306/student"

maxActive="3"

/

/GlobalNamingResources

name:指定连接池的名称

type:指定连接池的类,他负责连接池的事务处理

url:指定要连接的数据库

driverClassName:指定连接数据库使用的驱动程序

username:数据库用户名

password:数据库密码

maxWait:指定最大建立连接等待时间,如果超过此时间将接到异常

maxIdle:指定连接池中连接的最大空闲数

maxActive:指定连接池最大连接数

3、配置web.xml文件。

web-app

resource-ref

descriptionmysql数据库连接池配置/description

res-ref-namejdbc/DBPool/res-ref-name

res-typejavax.sql.DataSource/res-type

res-authContainer/res-auth

res-sharing-scopeShareable/res-sharing-scope

/resource-ref

/web-app

4、配置context.xml文件

与server.xml文件所在的位置相同。

Context

ResourceLink

name="jdbc/DBPool"

type="javax.sql.DataSource"

global="jdbc/DBPool"

/

/Context

5、测试

DataSource pool = null;

Context env = null;

Connection conn = null;

Statement st = null;

ResultSet rs = null;

try{

env = (Context)new InitialContext().lookup("java:comp/env");

//检索指定的对象,返回此上下文的一个新实例

pool = (DataSource)env.lookup("jdbc/DBPool");

//获得数据库连接池

if(pool==null){out.printl("找不到指定的连接池!");}

con = pool.getConnection();

st = con.createStatement();

rs = st.executeQuery("select * from student");

}catch(Exception ex){out.printl(ne.toString());}

swoole mysql连接池 有什么用

对mysql那一端形成一个远程过程的调用,通过XDR数据结构进行解析mysql传来的数据项(RPC也为sun最新提出并后来在linux上默认支持),也就是说像用户登录验证这一块用Mysql的长连接来实现,提高其效率运行相当稳定!