最近开发人员那边总说他们的程序连接一台指定服务器的时候出现闪断的现象,有连接失败的日志生成.于是就登陆到这台机器上探查个究竟,看了下mysql的错误日志,发现有mysql崩溃的现象,数据目录下面生成好多的bin文件,错误日志里面的内容如下:

090922  1:10:39 - mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

We will try our best to scrape up some info that will hopefully help diagnose

the problem, but since we have already crashed, something is definitely wrong

and this may fail.

key_buffer_size=16777216

read_buffer_size=262144

max_used_connections=61

max_threads=151

threads_connected=50

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133312 K

bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

这里只贴出来了一部分的内容,错误日志里面有大量相同的错误,看来mysql的崩溃和这个有很多的关系,于是就在网上搜下原因,找了好久都没有找到解决的方法,最后去了mysql的官方网站溜达了下,发现有个人提出来了一个方法就是通过ulimit -a 看相关的信息,主要是看 open file这项,于是就在本数据库服务器看了下,数据是1024,然后用ulimit -n 进行了修改 使其改的大一些,但是发现有些问题,我下次登录这台服务器的时候发现这个选项有变会到了1024,很是奇怪.于是又找了找其他的方法,下面方法是比较完美的:

#vi /etc/security/limits.conf

在下面添加如下的一行

* -  nofile 65536

#vi /etc/pam.d/login

在下面添加如下的一行

session    required     /lib/security/pam_limits.so

OK,然后再用ulimit -a 看下 发现已经改过来了,再没有返回到1024了,通过一下午的检测,再没有发现mysql的崩溃,继续检测,看近2天还会不会发生崩溃了,要是不是就是这个原因导致的问题.