Question

我有一个应用程序服务器（linux盒子上的jetty 6），托管15个人应用程序（个人战争）。每隔3或4天，我会收到来自nagios的关于打开TCP连接数量的警报。经过检查，我发现绝大多数这些连接都是针对MySQL服务器的。

netstat -ntu | grep TIME_WAIT

从应用程序服务器显示MySQL服务器上的10,000多个连接（注意状态为TIME_WAIT）。如果我重新启动jetty，连接几乎为零。

来自节目状态的一些有趣的值：

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

“show processlist”没有显示任何异常（这是我所期望的，因为大多数连接都是空闲的 - 请记住上面的TIME_WAIT状态）。

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

我有什么想法可以追踪抓住所有这些连接并永不放弃的应用程序？

Answer 1

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

wait_timeout=60
interactive_timeout=60

我在这里找到它（一直在底部）：http://community.livejournal.com/mysql/82879.html

杀死过时连接的默认等待时间是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 reload将不会重新加载你的my.cnf（参见下面的链接）

Answer 2

可能连接池配置错误，无法保持太多连接，并且它们会持续太多空闲进程。

除此之外，我能想到的是，某些代码保留在结果集上，而这似乎不太可能。为了捕获它是否是一个缓慢的查询超时，你还可以设置mysql写入conf文件中的慢查询日志，然后它将写入所有花费超过X秒的查询（默认为5，我认为）。

Answer 3

好吧，我想到的一件事（虽然我不是这方面的专家）是增加对mySQL的日志记录并搜索所有连接/关闭消息。如果这不起作用，你可以编写一个小代理，放在实际的mySQL服务器和你的应用程序套件之间进行额外的日志记录，你就会知道谁在连接/离开。

Answer 4

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

Answer 5

我的客户端服务器上的+30,000 TIME_WAIT遇到了同样的问题。通过在/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分钟后，TIME_WAIT连接从30 000到7 000。

Answer 6

RHEL7.tcp_tw_reuse中的

/ proc / sys / net / ipv4 / tcp_fin_timeout为60，tcp_tw_recycle更改为1，性能得到改善。

追踪MySQL连接泄漏

6 个答案: