重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
mysql的最大连接数默认是100,
网站建设哪家好,找创新互联公司!专注于网页设计、网站建设、微信开发、小程序定制开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了仲巴免费建站欢迎大家使用!
这个数值对于并发连接很多的数据库应用是远远不够的,当连接请求大于默认连接数后,就会出现无法连接数据库的错误,因此我们需要把它适当调大一些。
调节方法为:
1.linux服务器中
:改my.cnf中的值就行了
2.Windows服务器中(我用的):
在文件“my.ini”中找到段
[mysqld],在其中添加一行
max_connections=200###
200可以更改为想设置成的值.
然后重启"mysql"服务。
/mysqladmin所在路径/mysqladmin
-uroot
-p
variables
输入root数据库账号的密码后可看到
|
max_connections
|
1000
|
其他需注意的:
在编程时,由于用mysql语句调用数据库时,在每次之执行语句前,会做一个临时的变量用来打开数据库,所以你在使用mysql语句的时候,记得在每次调用完mysql之后就关闭mysql临时变量。
另外对于访问量大的,可以考虑直接写到文本中,根据预测的访问量,先定义假若是100个文件文件名依次为1.
txt,2.
txt
100.
txt。
新安装后的mysql数据库,其默认的最大连接数为100。 方法一:在mysql安装路径下,找到my.ini或者my.cnf文件,打开它找到max_connections,设置成1000; 然后重启mysql服务。 方法二:在mysql运行环境下,进入mysql命令下: mysql set global max_connections=1000; 然后关闭mysql重启它; 在./bin路径下,使用 # ./mysqladmin -uroot -p123456 variables | grep "max_connections" 看到 | max_connections | 1000 | 说明新修改的连接数已经生效了。 也可以在mysql运行环境下,执行:mysql show variables; 查看max_connections的值。 也可以在mysql运行环境下,执行:mysql show status; 查看当前活动的连接线程值,即找到threads_connected的值就是了。 方法三:编辑mysqld_safe文件: # vi /usr/local/mysql/bin/mysqld_safe 找到msyqld启动的那两行,在后面加上参数: 然后重新启动mysql服务,就OK了。
遇到mysql超出最大连接数,相信不少人第一反应就是查看mysql进程,看有没有慢查询,当然这个做法是完全正确的!
但是很多时候真正的问题不在这里。
今天有遇到同样的问题,一味查看mysql进程和慢查询日志,无果。
后来老大提点了一下,查看一下nginx日志,发现有一两个访问执行时候比较长,然后使用top命令查看了一下服务器负载,惊了,居然超高!
最后发现原来有一台web分流主机挂了,导致另外几台web主机负载增高,从而导致了php-fpm的执行效率降低。
那么这跟mysql有什么关系呢?原因很简单,因为php执行时间过长,mysql连接迟迟未释放,就会导致连接数过多出现。
最后总结:其实很多时候,一个问题的根本原因并不是那么直接的呈现出来,需要自己去跟踪。
老大有一句很实用的话:遇到问题先查日志(mysql、php、nginx等)
===============================================================
排查连接数过多的方法
当用户收到链接数告警时,意味着连接数即将达到该实例的上限。如果实例的连接数超过了实例规定的连接数,将无法创建新的连接,这个时候会影响用户的业务;
Mysql 的连接通常是一个请求占用一个连接,如果该请求(update,insert,delete,select)长时间没有执行完毕,则会造成连接的堆积,迅速的消耗完数据库的连接数,这个时候技术支持人员就要登录数据库进行排序,看看到底是那些sql 占用了连接;
问题排查步骤:
1 、查看实例配置:
可登录RDS控制台“详情与配置”查看实例额定链接数,我们假设最高支持1500个链接
2、 查看当前的连接数:
1)可登录RDS控制台“性能监控”查看实例当前链接数。
2)或者登录数据库查询当前连接,可以使用同步账号或者用户的业务账号登录数据库,执行show processlist;
[root@r41d05036.xy2.aliyun.com ~]# mysql -uroot -h127.0.0.1 -P3020 -e “show processlist”|wc -l
1262
可以看到该实例已经有1262 个连接
3、排查是什么动作占用了这些连接:
[root@r41d05036.xy2.aliyun.com ~]# myql -uroot -h127.0.0.1 -P3018 -e “show full processlist”/tmp/1.log
root@r14d11038.dg.aliyun.com # more /tmp/1.log
615083 my_db 223.4.49.212:54115 my_db Query 100 Sending data
INSERT INTO tmp_orders_modify (oid, tid, seller_id, status, gmt_create, gmt_modified)
SELECT oid, tid, seller_id, status, gmt_create, gmt_modified
FROM sys_info.orders WHERE
gmt_modified NAME_CONST(‘v_last’,_binary’2012-12-24 10:33:00’ COLLATE ‘binary’) AN
D gmt_modified = NAME_CONST(‘v_curr’,_binary’2012-12-24 10:32:00’ COLLATE ‘binary’)
621564 my_db 223.4.49.212:46596 my_db Query 3890 sorting result
insert into tmp_trades(sid, d, h, tc, tm, tp, ic, new_tp, old_tp)
select a.seller_id as sid,
…………..
from orders_1 as a where seller_id =1 and is_detail = ‘1’
and created date_format(‘2012-12-24 10:35:00’, ‘%Y-%m-%d %H:00:00’)
and gmt_create date_format(‘2012-12-24 10:40:00’, ‘%Y-%m-%d %H:%i:00’)
and gmt_create = date_format(‘2012-12-24 10:35:00’, ‘%Y-%m-%d%H:%i:00’)
group by d, h
order by d
……………….此处省略其他sql
4、分析连接占用的原因:
可以看到数据库中有长时间没有执行完成的sql,一直占用着连接没有释放,而应用的请求一直持续不断的涌入数据库,这个时候数据库的连接很快就被使用完;所以这个时候需要排查为什么这些sql 为什么长时间没有执行完毕,是索引没有创建好,还是sql执行耗时严重。
第一条sql:
INSERT INTO tmp_orders_modify (oid, tid, seller_id, status, gmt_create, gmt_modified)
SELECT oid, tid, seller_id, status, gmt_create, gmt_modified
FROM sys_info.orders WHERE
gmt_modified NAME_CONST(‘v_last’,_binary’2012-12-24 10:33:00’ COLLATE ‘binary’) AN
D gmt_modified = NAME_CONST(‘v_curr’,_binary’2012-12-24 10:32:00’ COLLATE ‘binary’)
是用户从sys_info 数据库中拉取订单到自己的业务库中那个,但是在orders 表上没有gmt_modified 的索引,导致了全表扫描;(更加详尽的排查方法可以参考:为什么我的RDS慢了);
第二条sql:
看到这条sql 正在进行sorting 排序,为什么导致sql 长时间sorting,通常情况下为排序的结果集太大导致排序不能在内存中完成,需要到磁盘上排序,进而导致了性能的下降;解决的办法就是降低排序的结果集,常用的手段是利用索引的有序性,消除排序,或者建立适当的索引减小结果集;我们可以看到第二条sql 的排序字段非常的复杂,但是我们可以看到查询的时间范围是很短,只有5 分钟的时间间隔,这个时候就可以在gmt_create上创建一个索引,过滤掉大部分的记录:
Alter tale order_1 add index ind_order_gmt_create(gmt_create);
(该用户对orders 进行了分表,大概有50 多张分表需要添加gmt_create 字段的索引);
5、经过上面两步的优化后,用户实例恢复正常:io 情况和connection 情况,可再次登录RDS控制台查看连接数。