您好,欢迎来到思海网络,我们将竭诚为您提供优质的服务! 诚征网络推广 | 网站备案 | 帮助中心 | 软件下载 | 购买流程 | 付款方式 | 联系我们 [ 会员登录/注册 ]
促销推广
客服中心
业务咨询
有事点击这里…  531199185
有事点击这里…  61352289
点击这里给我发消息  81721488
有事点击这里…  376585780
有事点击这里…  872642803
有事点击这里…  459248018
有事点击这里…  61352288
有事点击这里…  380791050
技术支持
有事点击这里…  714236853
有事点击这里…  719304487
有事点击这里…  1208894568
有事点击这里…  61352289
在线客服
有事点击这里…  531199185
有事点击这里…  61352288
有事点击这里…  983054746
有事点击这里…  893984210
当前位置:首页 >> 技术文章 >> 文章浏览
技术文章

详解MySQL数据库资源不足的错误解决方案

添加时间:2014-2-23 17:46:48  添加: 思海网络 

前几天,在管理系统的时候遇到一个奇怪的问题, 今天才有机会安装好MySQL环境来重现此问题,由于不是最原始的环境, 所以未必能够完全重现, 我只能努力重现关键问题了.. 我觉得此问题有点特别, 故在此大概的回想下当时的情景..

工作时, 执行了一个su – mysql 的命令, 遇到了下面这样一个错误..

view sourceprint?1 [root@dbmain ~]# su - mysql 

2 su: cannot set user id: Resource temporarily unavailable

这是一个Shell中由于资源不足引起的问题, 当时下意识的先运行ulimit,看看ulimit的基本限制.

view sourceprint?01 [root@dbmain ~]# ulimit -a 

02 core file size          (blocks, -c) 0 

03 data seg size           (kbytes, -d) unlimited 

04 scheduling priority             (-e) 0 

05 file size               (blocks, -f) unlimited 

06 pending signals                 (-i) 25600 

07 max locked memory       (kbytes, -l) 32 

08 max memory size         (kbytes, -m) unlimited 

09 open files                      (-n) 1024 

10 pipe size            (512 bytes, -p) 8 

11 POSIX message queues     (bytes, -q) 819200 

12 real-time priority              (-r) 0 

13 stack size              (kbytes, -s) 10240 

14 cpu time               (seconds, -t) unlimited 

15 max user processes              (-u) 25600 

16 virtual memory          (kbytes, -v) unlimited 

17 file locks                      (-x) unlimited

又看了看,/etc/security/limits.conf

view sourceprint?01 oracle              soft    nproc   2047 

02 oracle              hard    nproc   16384 

03 oracle              soft    nofile  1024 

04 oracle              hard    nofile  65536 

05 oracle              soft    memlock        12582912 

06 oracle              hard   memlock        12582912 

07   

08 grid              soft    nproc   2047 

09 grid              hard    nproc   16384 

10 grid              soft    nofile  1024 

11 grid              hard    nofile  65536 

12 grid              soft    memlock        12582912 

13 grid              hard   memlock        12582912 

14   

15 mysql             soft    nproc  500 

16 mysql             hard    nproc  500 

17 mysql             soft    nofile  1024 

18 mysql             hard    nofile  65536 

19 mysql             soft    memlock  12582912 

20 mysql             hard    memlock  12582912

经过分析,怀疑也只有process/file这两个出现资源紧张的概率比较大.. 因此就先ps -ef 看系统中该用户的进程数量..

view sourceprint?1 [root@dbmain ~]# ps -ef grep mysql 

2 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 

3 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 

4 root     15171 17507  0 13:26 pts/2    00:00:00 mysql -uroot -p 

5 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、线程

分享到:

顶部 】 【 关闭
版权所有:佛山思海电脑网络有限公司 ©1998-2024 All Rights Reserved.
联系电话:(0757)22630313、22633833
中华人民共和国增值电信业务经营许可证: 粤B1.B2-20030321 备案号:粤B2-20030321-1
网站公安备案编号:44060602000007 交互式栏目专项备案编号:200303DD003  
察察 工商 网安 举报有奖  警警  手机打开网站