MySQL Sleep进程

Posted 2020-09-12 异想天开

mysql中查询当前的连接数：

mysql> show status like ‘%Threads_connected%‘;

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 27    | 
+-------------------+-------+
1 row in set (0.00 sec)

查询最大连接数：

show variables like ‘%max_connections%‘;
set GLOBAL max_connections=800;
flush privileges
也可以修改/etc/my.cnf中的max_connections：
max_connections = 1000

     在mysql客户端下执行show processlist可以看到很多sleep的进程，这些进程就是人们常说的死连接，它们会一直保持sleep，直到my.cnf里面设置的wait_timeout这个参数值的时间到了，mysql才会自己杀死它。在杀死它的时候，mysql还会在error-log里面记录一条Aborted connection xxx to db: ‘xxx‘ user: ‘xxx‘ host: ‘xxx‘的日志，用google翻译一下，会得到一个相当强悍的解释"胎死腹中的连接"!

   可以通过如下命令查看系统设置的超时时间：

show global variables like ‘%timeout‘;
set global wait_timeout = 10;

    那么造成sleep的原因，有三个，下面是mysql手册给出的解释:

• 客户端程序在退出之前没有调用mysql_close()。(写程序的疏忽，或者数据库的db类库没有自动关闭每次的连接)
• 客户端sleep的时间在wait_timeout或interactive_timeout规定的秒内没有发出任何请求到服务器. (类似常连，类似于不完整的tcp ip协议构造，服务端一直认为客户端仍然存在（有可能客户端已经断掉了）)
• 客户端程序在结束之前向服务器发送了请求还没得到返回结果就结束掉了. (参看：tcp ip协议的三次握手)

    配置MySQL里的参数。超时时间设置。

• max_connections：

          允许的同时客户的数量。负载过大时，你将经常看到 too many connections 错误。已达到最大链接数，所以会出现这种情况。

• wait_timeout            

         服务器在关闭连接之前在一个连接上等待行动的秒数，默认数值是28800，即如果没有事情发生，服务器在 8个小时后关闭连接。防止sleep过多而导致出现too many connections。

        如果你的sleep进程数在同一时间内过多，再加上其他状态的连接，总数超过了max_connection的值，那mysql除了root用户外，就无法再继续处理任何请求无法与任何请求建立连接或者直接down了。所以，这个问题在大负载的情况下还是相当严重的。如果发现你的mysql有很多死连接存在，首先要先检查你的程序是否使用的是pconnect的方式，其次，检查在页面执行完毕前是否及时调用了mysql_close()。
        还有一个办法，你可以在my.cnf里面加上wait_timeout和interactive_timeout，把他们的值设的小一些，默认情况下wait_timeout的值是8小时的时间，你可以改成1个小时，或半个小时。这样mysql会更快的杀死死连接。防止连接总数超过max_connection的值。或者把max_connection的值设置的更大，不过这样显然不妥，连接的数量越多，对你服务器的压力越大。实际上那些连接都是冗余的，把它们尽快杀死才是上策。

      wait_timeout过大有弊端，其体现就是MySQL里大量的sleep进程无法及时释放，拖累系统性能，不过也不能把这个指设置的过小，否则你可能会遭遇到“MySQL has gone away”之类的问题，通常来说，我觉得把wait_timeout设置为10是个不错的选择，但某些情况下可能也会出问题，比如说有一个CRON脚本，其中两次SQL查询的间隔时间大于10秒的话，那么这个设置就有问题了(当然，这也不是不能解决的问题，你可以在程序里时不时mysql_ping一下，以便服务器知道你还活着，重新计算wait_timeout时间).

 参见：http://www.blogjava.net/xiaomage234/archive/2010/04/12/318046.html

http://blog.csdn.net/starnight_cbj/article/details/4492555