前幾天，在管理系統的時候遇到一個奇怪的問題, 今天才有機會安裝好MySQL環境來重現此問題,由于不是最原始的環境, 所以未必能夠完全重現, 我只能努力重現關鍵問題了.. 我覺得此問題有點特別, 故在此大概的回想下當時的情景..

工作時, 執行了一個su – mysql 的命令, 遇到了下面這樣一個錯誤..

view sourceprint?1 [root@dbmain ~]# su - mysql 

2 su: cannot set user id: Resource temporarily unavailable

這是一個Shell中由于資源不足引起的問題, 當時下意識的先運行ulimit,看看ulimit的基本限制.

view sourceprint?01 [root@dbmain ~]# ulimit -a 

02 core file size          (blocks, -c) 0 

03 data seg size           (kbytes, -d) unlimited 

04 scheduling priority             (-e) 0 

05 file size               (blocks, -f) unlimited 

06 pending signals                 (-i) 25600 

07 max locked memory       (kbytes, -l) 32 

08 max memory size         (kbytes, -m) unlimited 

09 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) 25600 

16 virtual memory          (kbytes, -v) unlimited 

17 file locks                      (-x) unlimited

又看了看,/etc/security/limits.conf

view sourceprint?01 oracle              soft    nproc   2047 

02 oracle              hard    nproc   16384 

03 oracle              soft    nofile  1024 

04 oracle              hard    nofile  65536 

05 oracle              soft    memlock        12582912 

06 oracle              hard   memlock        12582912 

07   

08 grid              soft    nproc   2047 

09 grid              hard    nproc   16384 

10 grid              soft    nofile  1024 

11 grid              hard    nofile  65536 

12 grid              soft    memlock        12582912 

13 grid              hard   memlock        12582912 

14   

15 mysql             soft    nproc  500 

16 mysql             hard    nproc  500 

17 mysql             soft    nofile  1024 

18 mysql             hard    nofile  65536 

19 mysql             soft    memlock  12582912 

20 mysql             hard    memlock  12582912

經過分析,懷疑也只有process/file這兩個出現資源緊張的概率比較大.. 因此就先ps -ef 看系統中該用戶的進程數量..

view sourceprint?1 [root@dbmain ~]# ps -ef grep mysql 

2 root      4733     1  0 10:30 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/dbmain.pid 

3 mysql     4788  4733  0 10:30 ?        00:00:04 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --log-error=/var/lib/mysql/dbmain.err --pid-file=/var/lib/mysql/dbmain.pid 

4 root     15171 17507  0 13:26 pts/2    00:00:00 mysql -uroot -p 

5 root     20792 17163  0 15:30 pts/1    00:00:00 grep mysql

從這個輸出,,我們暫時排除nproc超標的可能性.

由此, 就根據此進程的pid進入其proc目錄查看當前打開的文件數量..

發現有大量socket的文件連接.. 但是其數量遠遠未達到文件數的限制, 由此懷疑可能是MySQL的線程也會消耗掉Linux系統的nproc基數, 因此嘗試調整/etc/security/limits.conf文件的nproc參數的值.

發現調整過后, su – mysql 確實可以成功執行了,,后面又將此參數改回, 重新執行su – mysql,,此問題又再次重現..由此確認,,使用MySQL的系統, 在設置MySQL的參數max_connections之外, 還需要考慮設置/etc/security/limits.conf文件的大小, MySQL是線程模式執行的, 其線程數也會被統計在nproc中, 這可能掩蓋或造成對此問題的誤判..
 關鍵字：MySQL、線程