资源报警后RabbitMQ服务器上的额外TCP连接

Question

我在Windows上安装了RabbitMQ Server 3.6.0（我知道是时候升级了，我已经在其他服务器节点上完成了这个。）

在服务器端和客户端都启用了心跳（心跳间隔60秒）。

我有资源警报（RAM限制），之后我观察到与RMQ Server的TCP连接数量的增加。

目前有18000个连接，而正常数量为6000个。

通过管理插件我可以看到有很多与0通道的连接，而我们的“普通”连接至少有1个通道。

即使RMQ服务器重启也无济于事：所有连接都会重新建立。

1.这是否意味着所有人都活着？

这里描述了类似的问题https://github.com/rabbitmq/rabbitmq-server/issues/384，但正如我所看到的那样，它已在v3.6.0中完全修复。

2.我是否理解在RMQ Server v3.6.0之前资源警报之后的行为是这样的：每1个真实客户端自动恢复连接可能在服务器端挂起几个TCP连接？

也许很重要：我们在服务器和客户端之间都有haProxy。

3. haProxy可以解释这个额外的连接吗？也许它会阻止客户端接收由于资源警报而关闭连接的信号？

Answer 1

  

  
1. 他们都还活着吗？
  

只有你可以回答这个问题，但我会问 - 你最终会得到成千上万的联系？实际上，您应该只为每个逻辑进程创建一个连接。因此，如果您真的有6,000个逻辑进程连接到服务器，那可能是许多连接的原因，但在我看来，即使在这种情况下，您也远远超出了合理的设计限制。

要检查，请查看在您终止其中一个逻辑进程时连接数减少了多少。

  

  
1. 我是否理解在RMQ Server v3.6.0之前资源警报之后的行为是这样的：每1个真实客户端自动恢复连接可能在服务器端挂起几个TCP连接？
  

据我所知，是的。在这种情况下，开发人员似乎遇到common problem in sockets，这就是检测到连接断开。如果每次有人误解TCP的工作方式我都有一美元，我就会比Bezos有更多的钱。所以，他们发现有人做了一些错误的假设，当需要实际读取或写入来检测死套接字时，开发人员编写代码（尝试）来正确处理它。重要的是要注意，这看起来不是一个非常全面的修复，所以如果概念设计问题已经引入代码的另一部分，那么这个bug可能仍然以某种形式存在。搜索错误报告可能会给您一个更详细的答案，或者询问该支持列表中的某个人。

  

  
1. haProxy可以解释这个额外的连接吗？
  

这取决于。理论上，haProxy只是一个传递。对于要由代理识别的连接，它必须经过握手，这是一个有意识的过程，不会无意中发生。关闭连接还需要握手，这是haProxy可能成为罪魁祸首的地方。如果haProxy认为连接已经死亡并且在没有该过程的情况下将其丢弃，那么它可能是一个促成因素。但它本身并没有建立这些新的联系。

Answer 2

RabbitMQ团队监控this mailing list，有时只回答StackOverflow上的问题。

我建议此用户从已知TCP连接问题的Erlang 18升级 -

https://groups.google.com/d/msg/rabbitmq-users/R3700QdIVJs/taDYKI6bAgAJ

Answer 3

我设法重现了这个问题：最后，这是我们的客户端使用RMQ连接的方式中的一个错误。 它创建了1个自动恢复连接（这一切都很好）和有时它为＆＃34;临时＆＃34;创建了一个单独的简单连接。目的。

重现我的问题的步骤是：

1. 在RabbitMQ中达到内存警报（例如，设置一个容易到达的RAM 限制和推动很多大消息）。连接将处于状态 ＆＃34;阻挡＆＃34;
2. 使用这个新的＆＃34; temp＆＃34;开始从我们的客户发送消息连接。
3. 确保连接处于状态＆＃34;已阻止＆＃34;。
4. 不消除资源警报，重新启动RabbitMQ节点。
5. ＆＃34; temp＆＃34;连接本身就在这里！尽管事实上自动恢复 没有启用它。它继续发送心跳所以 服务器没有关闭它。

我们将修复客户端始终使用一个唯一的连接。 另外，我们当然会升级Erlang。