详解MySQL数据库资源不足的非常错误[MySQL防范]
本文“详解MySQL数据库资源不足的非常错误[MySQL防范]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
前几天,在管理系统的时刻碰到一个奇特的问题, 本日才有机会安装好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中, 这大概掩盖或造成对此问题的误判..
以上是“详解MySQL数据库资源不足的非常错误[MySQL防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
本文地址: | 与您的QQ/BBS好友分享! |