备注:这篇是2012年写出的文章,虽然时间久远,但有实践经验意义。发布到个人博客,以免丢失。
背景:今天同事说跑程序时MySQL总自动断开而后程序会停止,因为MySQL和程序是在同一台机器排除网络原因,后来随便找一个数据少的表,用select count(*) from news;一直不断的刷新,过一小会就会出现:
现象如下:
之前出现类似has gone away的时候是因为导入数据时max_allowed_packet值太小的原因,试着加大没有效果,接着看日志发现问题了如下:
----------------------------------------------------------mysql日志 -----------------------------------------------------------------------
背景:今天同事说跑程序时MySQL总自动断开而后程序会停止,因为MySQL和程序是在同一台机器排除网络原因,后来随便找一个数据少的表,用select count(*) from news;一直不断的刷新,过一小会就会出现:
现象如下:
MySQL server has gone away No connection. Trying TO reconnect...
之前出现类似has gone away的时候是因为导入数据时max_allowed_packet值太小的原因,试着加大没有效果,接着看日志发现问题了如下:
----------------------------------------------------------mysql日志 -----------------------------------------------------------------------
Nov 1216:05:09 spider mysqld[763]: 091112 16:05:09 [Warning] Could not
increase number of max_open_files to more than 1024(request:1210)
------------------------------------------------------------------------------------------------
接着查看MySQL的open_files_limit为1024,如下:
mysql>SHOW VARIABLES LIKE'open%';
+------------------+-------+| Variable_name | Value |
+------------------+-------+| open_files_limit |1024 |
+------------------+-------+1 row INSET(0.00 sec)
在/etc/my.cnf加入open_files_limit=8192后重启MySQL后查看不起作用(重点在于操作系统的文件打开数是否够)
接着查看了下系统默认的打开文件数
ulimit -n 1024
在/etc/security/limits.conf添加
* soft nofile 8192 * hard nofile 8192
重新登录并重启MySQL后查看
ulimit -n 8192
SHOW VARIABLES LIKE'open%';
+------------------+-------+| Variable_name | Value |
+------------------+-------+| open_files_limit |8192 |
+------------------+-------+1 row INSET(0.00 sec)
再次跑程序异常消失。