一个普通ERROR 1135 (HY000)错误引发的血案:

一个普通ERROR 1135 (HY000)错误引发的血案:   今天接到测试人员反应,测试环境前端应用程序无连接mysql数据库,登录mysql服务器,查看错误日志,发现有如下报错:

点击(
此处)折叠或打开

  1. ERROR 1135 (HY000): Can’t create a new thread (errno 11);if you are not out of available memory,you can consult the manual for a possible OS-dependent bug

第一反应感觉可能是跟ulimit限制连接数有关,文件描述符不够用。接下来检查配置件 /etc/security/limits.conf 相关结果如下:

点击(
此处)折叠或打开

  1. #for root
  2. root soft nofile 65535
  3. root hard nofile 65535
  4. End of file
  5. mysql soft nproc 65536
  6. mysql hard nproc 65536
  7. mysql soft nofile 65535
  8. mysql hard nofile 65535

配置没有问题,mysql的ulimit限制已经打开。

但是,执行如下命令:

点击(
此处)折叠或打开

  1. # sudo -u root bash -c  ulimit -a 
  2. core file size (blocks, -c) 0
  3. data seg size (kbytes, -d) unlimited
  4. scheduling priority (e) 0
  5. file size (blocks, -f) unlimited
  6. pending signals (i) 62591
  7. max locked memory (kbytes, -l) 64
  8. max memory size (kbytes, -m) unlimited
  9. open files (n) 1024
  10. pipe size (512 bytes, -p) 8
  11. POSIX message queues (bytes, -q) 819200
  12. real-time priority (r) 0
  13. stack size (kbytes, -s) 10240
  14. cpu time (seconds, -t) unlimited
  15. max user processes (u) 1024
  16. virtual memory (kbytes, -v) unlimited
  17. file locks (x) unlimited

  发现max user processes值仍为1024.

而在Centos5里面,只须在/etc/security/limits.conf添加如下两行:  

点击(
此处)折叠或打开

  1. root soft nofile 65535 
  2. root hard nofile 65535

  对应的uilmit  -u 就会是65535.   后来猜想centos6的用户的ulimit限制是不是还有其他的配置文件做相关的限制呢?果不其然,发现在 /etc/security/limits.d/目录下,有一个名为:90-nproc.conf的配置文件,

打开看看什么内容:   [root@fztest ~]# cat /etc/security/limits.d/90-nproc.conf

点击(
此处)折叠或打开

  1. # Default limit for number of user’s processes to prevent
  2. # accidental fork bombs.
  3. # See rhbz #432903 for reasoning.
  4. * soft nproc 1024

而在配置文件/etc/security/limits.d/90-nproc.conf中的 “* soft nproc 1024”的意思是任何用户的最大max user processes为1024个,也就是说,系统的任何用户均不可以通过ulimit -u来修改 。真的是这样吗?我们来进行如下验证操作:

点击(
此处)折叠或打开

  1. [oracle@fztest ~]$ ulimit -u 65535
  2. -bash: ulimit: max user processes: cannot modify limit: Operation not permitted
  3. [root@fztest ~]# ulimit -u 65535
  4. [root@fztest ~]# ulimit -u 
  5. 65535

由以上操作,可知事实上这个限制是对除root以外的普通用户进行的限制,root可以通过ulimit -u 65535来进行即时修改,只对当前会话生效。一旦重启服务器,便会失效(重新恢复max user processes  -u 1024)。

接下来,尝试通过修改这个配置文件,来验证max user processes的值是否会改变。 将/etc/security/limits.d/90-nproc.conf中的1024修改为65535后,执行如下命令:

点击(
此处)折叠或打开

  1. [root@fztest ~]# sudo -u root bash -c  ulimit -a 
  2. core file size (blocks, -c) 0
  3. data seg size (kbytes, -d) unlimited
  4. scheduling priority (e) 0
  5. file size (blocks, -f) unlimited
  6. pending signals (i) 95191
  7. max locked memory (kbytes, -l) 64
  8. max memory size (kbytes, -m) unlimited
  9. open files (n) 65535
  10. pipe size (512 bytes, -p) 8
  11. POSIX message queues (bytes, -q) 819200
  12. real-time priority (r) 0
  13. stack size (kbytes, -s) 10240
  14. cpu time (seconds, -t) unlimited
  15. max user processes (u) 65535
  16. virtual memory (kbytes, -v) unlimited
  17. file locks (x) unlimited

由此可见,修改生效。如果不想修改/etc/security/limits.d/90-nproc.conf这个文件,也可以将此限制添加到/etc/rc.local文件中,让其开机应用生效即可。   成功修改了root用户的max user processes后,继续使用root用户启动mysqld_safe脚本,稳定运行了一个上午,一切正常。 至此,ERROR 1135 (HY000): Can’t create a new thread (errno 11)这个问题总算告以段落。

 
     本文转自vcdog 51CTO博客,原文链接:http://blog.51cto.com/255361/1054204
,如需转载请自行联系原作者

点赞