亲宝软件园·资讯

展开

Mysql连接数设置和获取的方法

码客 人气:0
这篇文章主要介绍了Mysql连接数设置和获取的方法,帮助大家更好的理解和使用MySQL,感兴趣的朋友可以了解下

获取连接数

--- 获取最大连接数
SHOW VARIABLES LIKE '%max_connections%'; 

--- 获取连接列表
SHOW PROCESSLIST; 
--- 获取连接列表
SHOW FULL PROCESSLIST; 

--- 获取当前的链接信息 Threads_connected是当前的连接数
SHOW STATUS LIKE 'Threads%';

--- 获取连接统计 比如历史最大连接数以及最大连接时长等
SHOW STATUS LIKE '%Connection%';
mysql> SHOW STATUS LIKE 'Threads%';
+-------------------+-------+
| Variable_name   | Value |
+-------------------+-------+
| Threads_cached  | 58  |
| Threads_connected | 57  |  ---这个数值指的是打开的连接数
| Threads_created  | 3676 |
| Threads_running  | 4   |  ---这个数值指的是激活的连接数,这个数值一般远低于connected数值
+-------------------+-------+

Threads_connected 跟show processlist结果相同,表示当前连接数。准确的来说,Threads_running是代表当前并发数

设置连接数

临时设置

mysql>show variables like 'max_connections'; --- 查可以看当前的最大连接数
msyql>set global max_connections=1000; --- 设置最大连接数为1000,可以再次查看是否设置成功
mysql>exit --- 退出

永久设置
可以在/etc/my.cnf里面设置数据库的最大连接数

[mysqld]
max_connections = 1000

项目中连接池设置

下面公式由 PostgreSQL 提供,不过底层原理是不变的,它适用于市面上绝大部分数据库产品。还有,你应该模拟预期的访问量,并通过下面的公式先设置一个偏合理的值,然后在实际的测试中,通过微调,来寻找最合适的连接数大小。

连接数 = ((核心数 * 2) + 有效磁盘数)

核心数不应包含超线程(hyper thread),即使打开了超线程也是如此,如果热点数据全被缓存了,那么有效磁盘数实际是0,随着缓存命中率的下降,有效磁盘数也逐渐趋近于实际的磁盘数。另外需要注意,这一公式作用于SSD 的效果如何,尚未明了。
好了,按照这个公式,如果说你的服务器 CPU 是 4核 i7 的,连接池大小应该为 ((4*2)+1)=9。

取个整, 我们就设置为 10 吧。你这个行不行啊?10 也太小了吧!

你要是觉得不太行的话,可以跑个性能测试看看,我们可以保证,它能轻松支撑 3000 用户以 6000 TPS 的速率并发执行简单查询的场景。你还可以将连接池大小超过 10,那时,你会看到响应时长开始增加,TPS 开始下降。

你需要的是一个小连接池,和一个等待连接的线程队列

假设说你有 10000 个并发访问,而你设置了连接池大小为 10000,你怕是石乐志哦。

改成 1000,太高?改成 100?还是太多了。

你仅仅需要一个大小为 10 数据库连接池,然后让剩下的业务线程都在队列里等待就可以了。

连接池中的连接数量大小应该设置成:数据库能够有效同时进行的查询任务数(通常情况下来说不会高于 2*CPU核心数)。

你应该经常会看到一些用户量不是很大的 web 应用中,为应付大约十来个的并发,却将数据库连接池设置成 100, 200 的情况。请不要过度配置您的数据库连接池的大小。

是不是越大约好

模拟 9600 个并发线程来操作数据库,每两次数据库操作之间 sleep 550ms,注意,视频中刚开始设置的线程池大小为 2048。

让我们来看看数据库连接池的大小为 2048 性能测试结果的鬼样子:

每个请求要在连接池队列里等待 33ms,获得连接之后,执行SQL需要耗时77ms, CPU 消耗维持在 95% 左右;

接下来,我们将连接池的大小改小点,设置成 1024,其他测试参数不变,结果咋样?

“这里,获取连接等待时长基本不变,但是 SQL 的执行耗时降低了!”

哎呦,有长进哦!

接下来,我们再设置小些,连接池的大小降低到 96,并发数等其他参数不变,看看结果如何:

每个请求在连接池队列中的平均等待时间为 1ms, SQL 执行耗时为 2ms.

我去!什么鬼?

我们没调整任何东西,仅仅只是将数据库连接池的大小降低了,这样,就能把之前平均 100ms 响应时间缩短到了 3ms。吞吐量指数级上升啊!

你这也太溜了!

为啥有这种效果?

我们不妨想一下,为啥 Nginx 内部仅仅使用了 4 个线程,其性能就大大超越了 100 个进程的 Apache HTTPD 呢?追究其原因的话,回想一下计算机科学的基础知识,答案其实非常明显。

要知道,即使是单核 CPU 的计算机也能“同时”运行着数百个线程。但我们其实都知道,这只不过是操作系统快速切换时间片,跟我们玩的一个小把戏罢了。

一核 CPU同一时刻只能执行一个线程,然后操作系统切换上下文,CPU 核心快速调度,执行另一个线程的代码,不停反复,给我们造成了所有进程同时运行假象。

其实,在一核 CPU 的机器上,顺序执行A和B永远比通过时间分片切换“同时”执行A和B要快,其中原因,学过操作系统这门课程的童鞋应该很清楚。一旦线程的数量超过了 CPU 核心的数量,再增加线程数系统就只会更慢,而不是更快,因为这里涉及到上下文切换耗费的额外的性能。

说到这里,应该恍然大悟了 ……

加载全部内容

相关教程
猜你喜欢
用户评论