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

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

[root@dbmain ~]# su - mysql   
su: cannot set user id: Resource temporarily unavailable  

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

[root@dbmain ~]# 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) 25600   
max locked memory       (kbytes, -l) 32   
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) 25600   
virtual memory          (kbytes, -v) unlimited   
file locks                      (-x) unlimited 

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

oracle              soft    nproc   2047   
oracle              hard    nproc   16384   
oracle              soft    nofile  1024   
oracle              hard    nofile  65536   
oracle              soft    memlock        12582912   
oracle              hard   memlock        12582912   
grid              soft    nproc   2047   
grid              hard    nproc   16384   
grid              soft    nofile  1024   
grid              hard    nofile  65536   
grid              soft    memlock        12582912   
grid              hard   memlock        12582912   
mysql             soft    nproc  500   
mysql             hard    nproc  500   
mysql             soft    nofile  1024   
mysql             hard    nofile  65536   
mysql             soft    memlock  12582912   
mysql             hard    memlock  12582912 

經(jīng)過分析,懷疑也只有process/file這兩個出現(xiàn)資源緊張的概率比較大.. 因此就先ps -ef 看系統(tǒng)中該用戶的進程數(shù)量..

[root@dbmain ~]# ps -ef | grep mysql   
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   
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   
root     15171 17507  0 13:26 pts/2    00:00:00 mysql -uroot -p   
root     20792 17163  0 15:30 pts/1    00:00:00 grep mysql 

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

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

發(fā)現(xiàn)有大量socket的文件連接.. 但是其數(shù)量遠遠未達到文件數(shù)的限制, 由此懷疑可能是MySQL的線程也會消耗掉Linux系統(tǒng)的nproc基數(shù), 因此嘗試調(diào)整/etc/security/limits.conf文件的nproc參數(shù)的值.

發(fā)現(xiàn)調(diào)整過后, su – mysql 確實可以成功執(zhí)行了,,后面又將此參數(shù)改回, 重新執(zhí)行su – mysql,,此問題又再次重現(xiàn)..由此確認,,使用MySQL的系統(tǒng), 在設置MySQL的參數(shù)max_connections之外, 還需要考慮設置/etc/security/limits.conf文件的大小, MySQL是線程模式執(zhí)行的, 其線程數(shù)也會被統(tǒng)計在nproc中, 這可能掩蓋或造成對此問題的誤判..

【編輯推薦】 

1. MySQL數(shù)據(jù)庫集群進行正確配置步驟
2. MySQL 集群在Server1與Server2上如何安裝MySQL
3. MySQL集群配置
4. MySQL集群自動安裝腳本
5. MySQL觸發(fā)器如何正確使用