MySQL连接数过多导致服务无法正常运行

Mysql并发和连接数


mysql并发数:netstat -ant |find /i "ESTABLISHED" |find /i ":3306 " /c 


mysql连接数:select count(*) from information_schema.processlist;
             或者:mysql -uroot -h127.0.0.1 -P3020 -e “show processlist”|wc -l >/tmp/1.log
             或者:  show full processlist;
show variables like 'max_connections';


./mysql -uroot -p1234.com -e 'show status' | grep -i  Threads 
show status like 'Threads%';


MySQL繁忙的时候运行show processlist,会发现有很多行输出,每行输出对应一个MySQL连接。怎么诊断发起连接的进程是哪个?它当前正在干嘛呢?


首先,需要通过TCP Socket而不是Unix Socket连接MySQL,这样在show processlist的输出中就会有来源端口号。


然后杀掉线程


可以先授权某一个用户,然后隔一定时间(30s)执行类似 show status 的命令,探针进行抓取,然后这些数据进行统计收集

【案例分析】遇到mysql超出最大连接数,相信不少人第一反应就是查看mysql进程,看有没有慢查询,当然这个做法是完全正确的!

但是很多时候真正的问题不在这里。
今天有遇到同样的问题,一味查看mysql进程和慢查询日志,无果。
后来老大提点了一下,查看一下nginx日志,发现有一两个访问执行时候比较长,然后使用top命令查看了一下服务器负载,惊了,居然超高!
最后发现原来有一台web分流主机挂了,导致另外几台web主机负载增高,从而导致了php-fpm的执行效率降低。
那么这跟mysql有什么关系呢?原因很简单,因为php执行时间过长,mysql连接迟迟未释放,就会导致连接数过多出现。
最后总结:其实很多时候,一个问题的根本原因并不是那么直接的呈现出来,需要自己去跟踪。
有一句很实用的话:遇到问题先查日志(mysql、php、nginx、tomcat等)

 ===============================================================

排查连接数过多的方法

当用户收到链接数告警时,意味着连接数即将达到该实例的上限。如果实例的连接数超过了实例规定的连接数,将无法创建新的连接,这个时候会影响用户的业务

Mysql 的连接通常是一个请求占用一个连接,如果该请求(update,insert,delete,select)长时间没有执行完毕,则会造成连接的堆积,迅速的消耗完数据库的连接数,这个时候技术支持人员就要登录数据库进行排序,看看到底是那些sql 占用了连接;

问题排查步骤:

1 、查看实例配置:

可登录RDS控制台“详情与配置”查看实例额定链接数,我们假设最高支持1500个链接

 

2、 查看当前的连接数:

1)可登录RDS控制台“性能监控”查看实例当前链接数。

2)或者登录数据库查询当前连接,可以使用同步账号或者用户的业务账号登录数据库,执行show processlist;

[[email protected] ~]# mysql -uroot -h127.0.0.1 -P3020 -e “show processlist”|wc -l

1262

可以看到该实例已经有1262 个连接

 

3、排查是什么动作占用了这些连接:

[[email protected] ~]# myql -uroot -h127.0.0.1 -P3018 -e “show full processlist”>/tmp/1.log

[email protected] # 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控制台查看连接数。


【对于Windows操作系统的】原因:windows系统BUG,微软官网有详细介绍,系统并发过大,连接数过多,部分socket连接无法释放关闭,而持续请求又导致无法释放的socket连接不断积压,最终导致No buffer space available


1.对于windows环境,可通过修改注册表进行配置:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

添加一个DWORD类型的值TcpTimedWaitDelay,值可以根据实际情况配置(可以配置十进制30秒)。

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters

添加一个DWORD类型的值MaxUserPort ,值可以根据实际情况配置(5000-65534)。

2.重启服务器

备注:
    TcpTimedWaitDelay:确定 TCP/IP 可释放已关闭连接并重用其资源前,必须经过的时间;缺省为240秒,最低为30秒,最高为300秒。建议设为30秒。
    MaxUserPort :确定在应用程序从系统请求可用用户端口时,TCP/IP 可指定的最高端口号;缺省值:无 建议值:至少十进制 32768

----------------------------------------------------

也可以将以下两行复制到空白txt中,保存关闭txt,然后再修改txt为bat,这样就变成了一个批处理文件,双击批处理即可完成上面所说的注册表里的添加

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "TcpTimedWaitDelay" /t REG_DWORD /d 30 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "MaxUserPort" /t REG_DWORD /d 65534 /f

导致原因:

出现这种错误明显就是 mysql_connect 之后忘记 mysql_close;
当大量的connect之后,就会出现Too many connections的错误,mysql默认的连接为100个,而什么情况下会出现这种错误呢?

正常的mysql_connect 之后调用 mysql_close()关闭连接
但在连接错误时,会者mysql_real_query()出现错误退出时,可能忘记mysql_close();
所以在程序return 之前一定要判断是否close(),最稳妥的方法就是在写任何函数时都只有一个出口!

附录模拟mysql连接增多的脚本

#!/bin/bash
set j=2
while true 
do
        let "j=j+1"
/usr/local/mysql/bin/mysqlslap -a -c 500 -i 10 -uroot -p1234.com
done
【推荐工具】

1、监视资源使用情况(系统监视器) | Microsoft Docs https://docs.microsoft.com/zh-cn/sql/relational-databases/performance-monitor/monitor-resource-usage-system-monitor

2、Cloud Insight - IT综合运维管理平台|数据库监控|IT基础设施监控 - OneAPM http://www.oneapm.com/ci/feature.html

【参考资料】

1、RDS for MySQL 连接数满情况的处理_MYSQL使用_技术运维问题_云数据库 RDS 版-阿里云 https://help.aliyun.com/knowledge_detail/41714.html

2、【Mysql】连接数过多,应急处理方法-yhdmy-ITPUB博客 http://blog.itpub.net/26148431/viewspace-2149247/

猜你喜欢

转载自blog.csdn.net/english0523/article/details/79911294