背景

有同學反應。產品連不上，登陸到server。發現連接數不夠了。

接著先重新啟動mysql，發如今mysql啟動的時候會報Waring

Warning Changed limits: max_open_files,max_connections=214

處理

/etc/security/limits.conf 中設置
* soft nofile 102400
* hard nofile 102400

登出server，又一次登錄。
重新啟動mysql，問題解決

過程

• 第一時間想到mysql配置得太小，于是找到配置。發現配置的max_connections=5000，明顯不是配置問題
• Linux系統上默認的open files數目為1024, 有時應用程序會報Too many open files的錯誤，是由于open files 數目不夠。

ulimit -a看下，果然是1024

疑問

為什么open files會決定max_connections大小?

max_connections和table_open_cache在系統上相應的是OS的文件句柄(fd)。假設這兩個值添加，那么相應的也要添加OS的max_open_files設置。不然mysql就會依據max_open_files的值，去主動調整這兩個設置。

參考：http://dev.mysql.com/doc/refman/5.5/en/table-cache.html

2015-07-22記

參數調整后。今天出現了client連接池用完。

在數據庫運行 show processlist; 發現大量的query end的process：

| 167 | paas | xxxxxx | edas | Query | 60400 | query end | INSERT INTO CON_METRIC (APP_ID, ECU_ID, MON_TYPE, MON_DATA, CREATE_TIME) VALUES ('ead5f836-c4c7-4ced |

insert、update、都有，狀態都是query end。

查看數據庫，cpu/內存都是正常。

發現磁盤滿了，最后定位到bin-log日志導致兩百多G被用完。

刪除掉早期的bin-log。恢復正常

總結

以上是生活随笔為你收集整理的Mysql启动自己主动设置max_connections为其它值的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。