前幾天，在管理系統的時候遇到一個奇怪的問題, 今天才有機會安裝好MySQL環境來重現此問題,由於不是最原始的環境, 所以未必能夠完全重現, 我只能努力重現關鍵問題了.. 我覺得此問題有點特別, 故在此大概的回想下當時的情景..
工作時, 執行了一個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
經過分析,懷疑也只有process/file這兩個出現資源緊張的概率比較大.. 因此就先ps -ef 看系統中該用戶的進程數量..
- [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超標的可能性.
由此, 就根據此進程的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中, 這可能掩蓋或造成對此問題的誤判..
編輯推薦】
