背景
有同学反应。产品连不上，登陆到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。恢复正常