MySQL连接的时候出现“too many connection"错误并且启动时间特别长的解决办法

昨天一台服务器上出现了一个奇怪的问题,正常访问的时候MySQL出现 "error 1040, too many connection" 错误提示,造成这个原因通常是max_connections设置的太小或者wait_timeout的值设置的太长造成连接超时时间太长。所以首先想到的是使用mysqladmin查看max_connections的值为多少

[root@localhost bin]$ ./mysqladmin -uroot -p variables | grep "max_conn"

输入数据库的密码之后就可以看到max_connections的值,如果太小的话(默认为100)需要将该值设置的大一些。如果MySQL不允许中断的话可以登录MySQL之后,然后设置当前max_connections的值

[root@localhost bin]$ ./mysql -uroot -p
mysql> set GLOBAL max_connections=1024;

这里还需要注意的是Linux下如果系统的max user processes低于max_connections的值会出现“Can't create a new thread (errno 11); ”错误,解决方法可以参考MySQL出现Can't create a new thread (errno 11); 的解决办法。上面的设置只是在当前运行的状态下有效,如果mysql重启之后设置失效了,所以终极的方法是修改mysql的配置文件my.cnf,然后在[mysqld]下面设置max_connections的值。

但是奇怪的是这样设置之后还是依然出现那个错误,于是登录mysql之后使用 show processlist; 命令查看连接,然后使用kill命令删除了一些Sleep状态的连接,但是过一会儿又会出现too many connection的错误提示。另外我还注意到一个现象,就是MySQL启动或重启的时候时间特别长,数据库大概有2G左右的数据,但是也不至于启动这么慢吧?后来想到是不是数据库文件有问题,于是又使用了修复命令对每个表进行了修复,但是过一两个小时之后还是会出现上面的错误。

正在一筹莫展的时候,突然想到会不会是硬盘分区被占满了?于是使用 dmidecode -t memory 命令,发现果然数据库所在的分区可用空间为0,原来是因为Nginx的日志文件累加了很长时间把磁盘给塞满了,于是将日志文件删除之后在重启MySQL之后就正常了。

参考资料:
MySQL提示“too many connections”的解决办法
mysql Too many connections

发表评论

电子邮件地址不会被公开。 必填项已用*标注