追踪MySQL连接泄漏

我有一个应用服务器（linux机箱上的jetty 6）承载15个个人应用程序（个人war）。每隔3或4天，我就会收到nagios关于打开的TCP连接数的警报。经过检查，我发现绝大多数连接都是到MySQL服务器的

netstat -ntu | grep TIME_WAIT

显示MySQL服务器上来自应用程序服务器的10000多个连接（注意状态为TIME\u WAIT）。如果我重新启动jetty，连接几乎为零

显示状态中的一些有趣值：

mysql> show status;
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| Aborted_clients          | 244       |
| Aborted_connects         | 695853860 |
| Connections              | 697203154 |
| Max_used_connections     | 77        |
+--------------------------+-----------+

“ShowProcessList”不会显示任何异常情况（这是我所期望的，因为大多数连接都是空闲的——记住上面的TIME_WAIT状态）

我有一个这个服务器的测试环境，但它从来没有任何问题。很明显，它没有获得太多的流量，而且应用程序服务器不断地重新启动，因此调试没有什么帮助。我想我可以深入研究每个应用程序并编写一个负载测试，这会影响数据库代码，但这会花费很多时间/麻烦

---

有什么办法可以让我追踪到一个应用程序，这个应用程序正在抓取所有这些连接并且从不放弃？

好吧，我想到的一件事（尽管我不是这方面的专家）是增加mySQL的登录量并搜索所有连接/关闭消息。如果这不起作用，您可以编写一个微型代理，位于实际的mySQL服务器和您的应用程序套件之间，执行额外的日志记录，这样您就可以知道谁正在连接/离开。

可能是连接池配置错误，占用了太多的连接，并且占用了太多的空闲进程

---

除此之外，我所能想到的就是一些代码保留了一个结果集，但这似乎不太可能。要捕获超时的慢速查询，您还可以将MySQL设置为写入conf文件中的慢速查询日志，然后它将写入所有耗时超过X秒的查询，默认值为10秒

答案似乎是在[mysqld]下的my.cnf中添加以下条目 :

我在这里找到它（一直在底部）：

终止过时连接的默认等待时间为22800秒。 要验证：

mysql> show variables like 'wait_%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 60    |
+---------------+-------+

编辑：我忘了提到，我还在/etc/sysctl.conf中添加了以下内容：

net.ipv4.tcp_fin_timeout = 15

这有助于降低操作系统在重用连接资源之前等待的阈值

---

编辑2:/etc/init.d/mysql重新加载不会真正重新加载my.cnf（请参见下面的链接）

显示进程列表显示每个线程的用户、主机和数据库。除非您的15个应用程序都使用相同的组合，否则您应该能够使用此信息进行区分。

我的客户端服务器上的+30000等待时间也有同样的问题。通过在

/etc/sysctl.conf

中添加以下内容修复了此问题：

net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_fin_timeout = 30 

然后：

/sbin/sysctl -p

---

2或3分钟后，等待连接的时间从30000变为7000。

/proc/sys/net/ipv4/tcp\u fin\u超时在RHEL7中为60。tcp\u tw\u重用和tcp\u tw\u回收被更改为1，性能得到了提高。

我可以在测试环境中执行此操作，但之后我又重新开始在db代码上编写负载测试（这样我可以在日志中获得一些活动）. 我希望通过一些MySQL魔术来跟踪到用户/schema/host/etc的死连接。为什么不增加生产服务器上的日志记录？从my.cnf的日志记录部分“注意，此日志类型是性能杀手”。此外，这需要重新启动PROD MySQL服务器。由于这个数据库服务器承载了许多其他的实时项目，我真的负担不起不必要的麻烦。我记录的查询速度很慢，这似乎不是什么问题。我查看了连接池配置，它们在我看来都很正常。池机制差异很大（DBCP、butterfly persistence、Hibernate/JPA、beenkeeper、iBatis等），因此我对自己发现错误配置的能力并不完全有信心。我不确定重载是否会在不完全重新启动的情况下重新加载设置。检查它的行为和文档。很好的一点-仅适用于活动连接-它不会显示过时的连接。

/sbin/sysctl -p