ERROR 1040(HY000): Too many connections：DB連接池里已有太多連接，不能再和你建立新連接。

數據庫自己有個連接池，你的每個系統部署在機器時，那臺機器上部署的系統實例/服務實例自己也有個連接池，你的系統每個連接Socket都對應DB連接池里的一個Socket連接，這就是TCP連接：

當MySQL告訴你Too many connections，就是在傳達它的連接池的連接已經滿了，你這業務系統不能再和它建立新的連接。

案例

DB部署在64G內存大機器，而連接這臺物理機的Java業務系統部署在2臺機器，Java系統的連接池最大大小為200，即每個Java業務系統節點，最多和MySQL建立200個連接，共最多建立400個連接。

但這時若MySQL報異常Too many Connections，說明目前MySQL無法建立400個網絡連接。這也太少了吧，這可是高配置機器!

于是檢查了my.cnf，有個關鍵參數是max_connections，即MySQL能建立的最大連接數，設置的800。那為啥兩臺機器就只需建立400個連接都不行?

登錄到MySQL機器，執行如下命令：

show variables like 'max_connections'

??可觀察到，當前MySQL僅建立了214個連接而已!難道MySQL根本不在乎我們設置的這參數?

檢查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!

Linux文件句柄數量被限制也會導致MySQL最大連接數被限制。

如何解決

核心就如下命令：

ulimit -HSn 65535

然后就能用如下命令，檢查最大文件句柄數是否被修改：

cat /etc/security/limits.conf cat /etc/rc.local

若都修改好之后，可在MySQL的my.cnf里確保max_connections參數也調整好了，然后重啟服務器、重啟MySQL，這樣linux的最大文件句柄就會生效，MySQL最大連接數也會生效了。

此時再嘗試業務系統去連接DB，就沒問題了。

為何Linux最大文件句柄限制為1024時，MySQL最大連接數是214?MySQL源碼中就是有個計算公式，算下來就是這樣的結果。

linux默認會限制你每個進程對機器資源的使用，包括：

• 可打開的文件句柄的限制
• 可打開的子進程數的限制
• 網絡緩存的限制
• 最大可鎖定的內存大小

因為linux os設計的初衷，就是要盡量避免你某個進程一下子耗盡機器上的所有資源，所以他默認都是會做限制的。

對我們來說，常見問題就是文件句柄的限制。

因為若linux限制你一個進程的文件句柄太少，就會導致我們無法創建大量網絡連接，我們的系統進程就無法正常工作。比如MySQL運行時，其實就是Linux上的一個進程，那么他其實是需要跟很多業務系統建立大量的連接的，結果你限制了他的最大文件句柄數量，那么他就不能建立太多連接了!

所以，你在生產環境部署了個系統，比如DB系統、MQ系統、存儲系統、Cache系統后，都需要調整Linux的一些內核參數，這個文件句柄數量一定要調整，通常得設為65535。

比如Kafka之類的MQ，在生產環境部署時，若不優化linux內核參數，會導致Kafka可能無法創建足夠的線程，此時也無法運行。

所以可用ulimit命令設置每個進程被限制使用的資源量，用

# 進程被限制使用的各種資源的量
ulimit -a

• core file size 進程崩潰時的轉儲文件的大小限制
• max locked memory 最大鎖定內存大小
• open files 最大可以打開的文件句柄數量
• max user processes就是最多前可進以擁有的子進程數量。久性的設置進程的資源

設置之后，要確保變更落地到/etc/security/limits.conf文件，永打印限制

所以執行ulimit -HSn 65535命令后，要用如下命令檢查一下是否落地到配置文件里去了。

cat /etc/security/limits.conf

cat /etc/rc.local