数据库生产故障，数据库无法连接的问题会看到的异常信息往往是
“ERROR 1040(HY000): Too many connections”，这个时候就是说数据库的连接池里已经有太多的连接了，不能再跟你建立新的连接了！机器上部署的系统实例/服务实例自己也是有一个连接池的，系统每个连接Socket都会对应着数据库连接池里的一个连接Socket，这就是TCP网络连接
数据库告诉你Too many connections的时候，就是说他的连接池的连接已经满了，你业务系统不能跟他建立更多的连接了！
系统文件句柄限制
案例
一个生产案例中，数据库部署在64GB的大内存物理机上，机器配置各方面都很高，然后连接这台物理机的Java系统部署在2台机器上，Java系统设置的连接池的最大大小是200，也就是说每台机器上部署的Java系统，最多跟MySQL数据库建立200个连接，一共最多建立400个连接，我们看下图示意。
这个时候如果MySQL报异常说Too many Connections，就说明目前MySQL甚至都无法建立400个网络连接？这也太少了吧！毕竟是高配置的数据库机器！
检查了一下MySQL的配置文件，my.cnf，里面有一个关键的参数是max_connections，就是MySQL能建立的最大连接数，设置的是800。那奇怪了，明明设置了MySQL最多可以建立800个连接，为什么居然两台机器要建立400个连接都不行呢？
登录到MySQL去，可以执行下面的命令
show variables like 'max_connections'
此时看到，当前MySQL仅仅只是建立了214个连接而已！所以此时就可以想到，是不是MySQL根本不管设置的那个
max_connections，就是直接强行把最大连接数设
置为214了？于是我们可以去检查一下MySQL的启动日志，可以看到如下的字样：Could not increase number of max_open_files to more than mysqld (request: 65535) Changed limits: max_connections: 214 (requested 2000) Changed limits: table_open_cache: 400 (requested 4096)
看看日志就很清楚了，MySQL发现自己无法设置
max_connections为我们期望的800，只能强行限制为214了！因为底层的linux操作系统把进程可以打开的文件句柄数限制为了1024了，导致MySQL最大连接数是214！
MySQL运行的时候，其实就是linux上的一个进程，需要跟很多业务系统建立大量的连接的，结果限制了系统最大文件句柄数量，那么系统就不能建立太多连接了！
在生产环境部署了一个系统，比如数据库系统、消息中间件系统、存储系统、缓存系统之后，都需要调整一下linux的一些内核参数，这个文件句柄的数量是一定要调整的，通常都得设置为
65535可以使用下面的命令:
ulimit -HSn 65535用如下命令检查最大文件句柄数是否被修改了:
cat /etc/security/limits.conf cat /etc/rc.local
都修改好之后，可以在MySQL的
my.cnf里确保max_connections参数也调整好了，然后可以重启服务器，然后重启MySQL，这样的话，linux的最大文件句柄就会生效了，MySQL的最大连接数也会生效了。我们平时可以用ulimit命令来设置每个进程被限制使用的资源量，用
ulimit -a就可以看到进程被限制使用的各种资源的量 比如 core file size 代表的进程崩溃时候的转储文件的大小限制，max locked memory就是最大锁定内存大小，open files就是最大可以打开的文件句柄数量，max user processes就是最多可以拥有的子进程数量。
设置之后，我们要确保变更落地到/etc/security/limits.conf文件里，永久性的设置进程的资源限制 所以执行ulimit -HSn 65535命令后，要检查一下是否落地到配置文件里去了。