zoukankan      html  css  js  c++  java
  • mysql超出最大连接数解决方法

    遇到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控制台查看连接数。

  • 相关阅读:
    DGA域名可以是色情网站域名
    使用cloudflare加速你的网站隐藏你的网站IP
    167. Two Sum II
    leetcode 563. Binary Tree Tilt
    python 多线程
    leetcode 404. Sum of Left Leaves
    leetcode 100. Same Tree
    leetcode 383. Ransom Note
    leetcode 122. Best Time to Buy and Sell Stock II
    天津Uber优步司机奖励政策(12月28日到12月29日)
  • 原文地址:https://www.cnblogs.com/yycc/p/7253893.html
Copyright © 2011-2022 走看看