39、案例实战：如何解决经典的Too many connections故障？背后原理是什么？
这篇文章继续上篇那个案例背景，其实就是经典的Too many connections故障，他的核心就是Linux的文件句柄限制，导致了MySQL的最大连接数被限制，那么今天来说下怎么解决这个问题
其实核心就是一行命令：
然后就可以用如下命令检查最大文件句柄数是否被修改了
如果都修改好之后，可以在MySQL的my.cnf里确保max_connectios参数也调整好了，然后可以重启服务器，然后重启MySQL，这样的话，Linux的最大文件句柄就会生效了，MySQL的最大连接数也会生效了。
然后此时你再尝试业务系统去连接数据库，就没问题了
另外再给大家解释一个问题，有人还是抑或说，为什么Linux的最大文件句柄限制为1024的时候，MySQL的最大连接是是214呢？
这个其实是MySQL源码内部写死的，他在源码中就是有一个计算公式，算下来就是如此罢了
然后再给大家说一个，这个Linux的ulimit命令是干嘛用的，其实是白了，Linux的话是默认会限制你每个进程对机器资源的使用的，包括可以打开的文件句柄的限制，可以打开的子进程数的限制，网络缓存的限制，最大可以锁定的内存大小。
因为Linux操作系统设计的初衷，就是要尽量避免你某个进程一下子耗尽机器上的所有资源，所以他默认都是会做限制的
那么对于我们来说，常见的一个问题，其实就是文件句柄的限制。
因为如果Linux限制你一个进程的文件句柄太少的话，那么就会导致我们没办法创建大量的网络连接，此时我们的系统进程就没法正常工作了
举个例子，比如MySQL运行的时候，其实就是Linux上的一个进程，那么他其实是需要跟很多业务系统建立大量的连接的，结果你限制了他的最大文件句柄数量，那么他就不能建立太多连接了
所以说，往往你在生产环境部署了一个系统，比如数据库系统、消息中间件系统、存储系统、缓存系统之后，都需要调整一下Linux的一些内核参数，这个文件句柄的数量是一定要调整的，通常都得设置为65535
还有比如Kafka之类的消息中间件，在生产环境部署的时候，如果你不优化一些Linux内核参数，会导致Kafka可能无法创建足够的线程，此时也是无法运行的
所以我们平时可以用ulimit命令来设置每个进程被限制使用的资源量，用ulimit -a就可以看到进程被限制使用的各种资源的量
比如core file size代表的进程崩溃时候的转储文件的大小限制，max locked memory就是最大锁定内存大小，open files就是最大可以打开的文件句柄数量，max user processes就是最多可以拥有的子进程数量。
设置之后，我们要确保变更落地到/etc/security/limits.conf文件里，永久性的设置进程的资源限制
所以执行ulimit -HSn 65535 命令后，要用如下命令检查一下是否落地到配置文件里去了
