详解MySQL数据库资源不足的错误解决方案
前几天，在管理系统的时候遇到一个奇怪的问题,今天才有机会安装好MySQL环境来重现此问题,由于不是最原始的环境,所以未必能够完全重现,我只能努力重现关键问题了..我觉得此问题有点特别,故在此大概的回想下当时的情景..
工作时,执行了一个su–mysql的命令,遇到了下面这样一个错误..
view sourceprint?1[root@dbmain~]#su-mysql
2su:cannot set user id:Resource temporarily unavailable
这是一个Shell中由于资源不足引起的问题,当时下意识的先运行ulimit,看看ulimit的基本限制.
view sourceprint?01[root@dbmain~]#ulimit-a
02core file size(blocks,-c)0
03data seg size(kbytes,-d)unlimited
04scheduling priority(-e)0
05file size(blocks,-f)unlimited
06pending signals(-i)25600
07max locked memory(kbytes,-l)32
08max memory size(kbytes,-m)unlimited
09open files(-n)1024
10pipe size(512bytes,-p)8
11POSIX message queues(bytes,-q)819200
12real-time priority(-r)0
13stack size(kbytes,-s)10240
14cpu time(seconds,-t)unlimited
15max user processes(-u)25600
16virtual memory(kbytes,-v)unlimited
17file locks(-x)unlimited
又看了看,/etc/security/limits.conf
view sourceprint?01oracle soft nproc2047
02oracle hard nproc16384
03oracle soft nofile1024
04oracle hard nofile65536
05oracle soft memlock12582912
06oracle hard memlock12582912
07
08grid soft nproc2047
09grid hard nproc16384
10grid soft nofile1024
11grid hard nofile65536
12grid soft memlock12582912
13grid hard memlock12582912
14
15mysql soft nproc500
16mysql hard nproc500
17mysql soft nofile1024
18mysql hard nofile65536
19mysql soft memlock12582912
20mysql hard memlock12582912
经过分析,怀疑也只有process/file这两个出现资源紧张的概率比较大..因此就先ps-ef看系统中该用户的进程数量..
view sourceprint?1[root@dbmain~]#ps-ef|grep mysql
2root47331010:30?00:00:00/bin/sh/usr/bin/mysqld_safe--datadir=/var/lib/mysql--pid-file=/var/lib/mysql/dbmain.pid
3mysql47884733010: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
4root1517117507013:26pts/200:00:00mysql-uroot-p
5root2079217163015:30pts/100:00:00grep 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中,这可能掩盖或造成对此问题的误判..