建站
咨詢
售后
建站咨詢
新聞中心
前幾天，在管理系統(tǒng)的時候遇到一個奇怪的問題, 今天才有機會安裝好MySQL環(huán)境來重現(xiàn)此問題,由于不是最原始的環(huán)境, 所以未必能夠完全重現(xiàn), 我只能努力重現(xiàn)關(guān)鍵問題了.. 我覺得此問題有點特別, 故在此大概的回想下當(dāng)時的情景..
成都創(chuàng)新互聯(lián)公司是網(wǎng)站建設(shè)技術(shù)企業(yè)，為成都企業(yè)提供專業(yè)的成都做網(wǎng)站、網(wǎng)站設(shè)計、外貿(mào)營銷網(wǎng)站建設(shè)，網(wǎng)站設(shè)計，網(wǎng)站制作，網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗和眾多成功案例，為您定制適合企業(yè)的網(wǎng)站。十多年品質(zhì)，值得信賴！
工作時, 執(zhí)行了一個su – mysql 的命令, 遇到了下面這樣一個錯誤..
- [root@dbmain ~]# su - mysql
- su: cannot set user id: Resource temporarily unavailable
這是一個Shell中由于資源不足引起的問題, 當(dāng)時下意識的先運行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超標(biāo)的可能性.
由此, 就根據(jù)此進程的pid進入其proc目錄查看當(dāng)前打開的文件數(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)..由此確認(rèn),,使用MySQL的系統(tǒng), 在設(shè)置MySQL的參數(shù)max_connections之外, 還需要考慮設(shè)置/etc/security/limits.conf文件的大小, MySQL是線程模式執(zhí)行的, 其線程數(shù)也會被統(tǒng)計在nproc中, 這可能掩蓋或造成對此問題的誤判..
新聞標(biāo)題：詳解MySQL數(shù)據(jù)庫資源不足的異常錯誤
網(wǎng)頁網(wǎng)址：http://www.5511xx.com/article/djiphej.html
