mysql中一個通俗ERROR 1135 (HY000)毛病激發的血案。本站提示廣大學習愛好者：（mysql中一個通俗ERROR 1135 (HY000)毛病激發的血案）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql中一個通俗ERROR 1135 (HY000)毛病激發的血案正文
明天接到測試人員反響，測試情況前端運用法式無銜接mysql數據庫，登錄mysql辦事器，檢查毛病日記，發明有以下報錯：
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 相干成果以下：
#for root
root soft nofile 65535
root hard nofile 65535
# End of file
mysql soft nproc 65536
mysql hard nproc 65536
mysql soft nofile 65535
mysql hard nofile 65535
設置裝備擺設沒有成績，mysql的ulimit限制曾經翻開。
然則，履行以下敕令：
# sudo -u root bash -c " ulimit -a "
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 62591
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
發明max user processes值仍為1024.
而在Centos5外面，只須在/etc/security/limits.conf添加以下兩行：
點擊(此處)折疊或翻開
root soft nofile 65535
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
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 1024
而在設置裝備擺設文件/etc/security/limits.d/90-nproc.conf中的 “* soft nproc 1024”的意思是任何用戶的最年夜max user processes為1024個，也就是說，體系的任何用戶均弗成以經由過程ulimit -u來修正 。真的是如許嗎?我們來停止以下驗證操作：
[oracle@fztest ~]$ ulimit -u 65535
-bash: ulimit: max user processes: cannot modify limit: Operation not permitted
[root@fztest ~]# ulimit -u 65535
[root@fztest ~]# ulimit -u
65535
由以上操作，可知現實上這個限制是對除root之外的通俗用戶停止的限制，root可以經由過程ulimit -u 65535來停止即時修正，只對以後會話失效。一旦重啟辦事器，便會掉效（從新恢復max user processes -u 1024）。
接上去，測驗考試經由過程修正這個設置裝備擺設文件，來驗證max user processes的值能否會轉變。
將/etc/security/limits.d/90-nproc.conf中的1024修正為65535後，履行以下敕令：
[root@fztest ~]# sudo -u root bash -c " ulimit -a"
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 95191
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 65535
virtual memory (kbytes, -v) unlimited
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)這個成績總算告以段落。
