詳解MySQL數(shù)據(jù)庫(kù)資源不足的異常錯(cuò)誤
前幾天，在管理系統(tǒng)的時(shí)候遇到一個(gè)奇怪的問題, 今天才有機(jī)會(huì)安裝好MySQL環(huán)境來(lái)重現(xiàn)此問題,由于不是最原始的環(huán)境, 所以未必能夠完全重現(xiàn), 我只能努力重現(xiàn)關(guān)鍵問題了.. 我覺得此問題有點(diǎn)特別, 故在此大概的回想下當(dāng)時(shí)的情景..
工作時(shí), 執(zhí)行了一個(gè)su – mysql 的命令, 遇到了下面這樣一個(gè)錯(cuò)誤..
- [root@dbmain ~]# su - mysql
- su: cannot set user id: Resource temporarily unavailable
這是一個(gè)Shell中由于資源不足引起的問題, 當(dāng)時(shí)下意識(shí)的先運(yùn)行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這兩個(gè)出現(xiàn)資源緊張的概率比較大.. 因此就先ps -ef 看系統(tǒng)中該用戶的進(jìn)程數(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
從這個(gè)輸出,,我們暫時(shí)排除nproc超標(biāo)的可能性.
由此, 就根據(jù)此進(jìn)程的pid進(jìn)入其proc目錄查看當(dāng)前打開的文件數(shù)量..
發(fā)現(xiàn)有大量socket的文件連接.. 但是其數(shù)量遠(yuǎn)遠(yuǎn)未達(dá)到文件數(shù)的限制, 由此懷疑可能是MySQL的線程也會(huì)消耗掉Linux系統(tǒng)的nproc基數(shù), 因此嘗試調(diào)整/etc/security/limits.conf文件的nproc參數(shù)的值.
發(fā)現(xiàn)調(diào)整過后, su – mysql 確實(shí)可以成功執(zhí)行了,,后面又將此參數(shù)改回, 重新執(zhí)行su – mysql,,此問題又再次重現(xiàn)..由此確認(rèn),,使用MySQL的系統(tǒng), 在設(shè)置MySQL的參數(shù)max_connections之外, 還需要考慮設(shè)置/etc/security/limits.conf文件的大小, MySQL是線程模式執(zhí)行的, 其線程數(shù)也會(huì)被統(tǒng)計(jì)在nproc中, 這可能掩蓋或造成對(duì)此問題的誤判..
【編輯推薦】
