但是很多时候真正的问题不在这里。
今天有遇到同样的问题，一味查看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控制台查看连接数。
1、mysql数据库系统允许的最大可连接数max_connections。这个参数是可以设置的。如果不设置，默认是100。最大是16384。2、数据库当前的连接线程数threads_connected。这是动态变化的。
查看max_connections、max_connections的办法见后。
如果
threads_connected
==
max_connections
时，数据库系统就不能提供更多的连接数了，这时，如果程序还想新建连接线程，数据库系统就会拒绝，如果程序没做太多的错误处理，就会出现类似强坛的报错信息。
因为创建和销毁数据库的连接，都会消耗系统的资源。而且为了避免在同一时间同时打开过多的连接线程，现在编程一般都使用所谓数据库连接池技术。
但数据库连接池技术，并不能避免程序错误导致连接资源消耗殆尽。
这种情况通常发生在程序未能及时释放数据库连接资源或其他原因造成数据库连接资源不能释放，但强坛系统估计不会发生这种低级的编程错误。
该错误的简便的检查办法是，在刷新强坛页面时，不断监视threads_connected的变化。如果max_connections足够大，而
threads_connected值不断增加以至达到max_connections，那么，就应该检查程序了。当然，如果采用数据库连接池技术，
threads_connected增长到数据库连接池的最大连接线程数时，就不再增长了。
从强坛出错的情况看，更大的可能性是数据库系统没能进行适当地配置。下面提出一点建议。供参考
让你们的工程师把mysql的最大允许连接数从默认的100调成32000。这就不会老出现连接过多的问题了。
查看max_connections
进入mysql，用命令：
show
variables
查看数据库最大可连接数的变量值：
max_connections
查看threads_connected
进入mysql，用命令：
show
status
查看当前活动的连接线程变量值：
threads_connected
设置max_connections
设置办法是在my.cnf文件中，添加下面的最后红色的一行：
[mysqld]
port=3306
#socket=mysql
skip-l
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）