首页 文章

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

提问于
浏览
1

我在Windows上安装了RabbitMQ Server 3.6.0(我知道是时候升级了,我已经在其他服务器节点上完成了) .

在服务器端和客户端都启用了心跳(心跳间隔60秒) .

我有一个资源警报(RAM限制),之后我观察到RMQ服务器的TCP连接数量的增加 .

目前有18000个连接,而正常数量是6000 .

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

甚至RMQ服务器重启也无济于事:所有连接都会重新 Build .

这是否意味着所有人都活着?

类似的问题在这里描述https://github.com/rabbitmq/rabbitmq-server/issues/384,但我可以看到它在v3.6.0中完全修复 .

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

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

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

3 回答

  • 0

    他们都活着吗?

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

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

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

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

    haProxy可以解释这个额外的连接吗?

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

  • 0

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


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

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

  • 1

    我've managed to reproduce the problem: in the end it was a bug in the way our client used RMQ connections. It created 1 auto-recovery connection (that'一切都很好) and 有时它为"temporary"目的创建了一个单独的简单连接 .

    重现我的问题的步骤是:

    • 在RabbitMQ中达到内存警报(例如,设置一个容易达到的RAM限制并推送大量的大消息) . 连接将处于"blocking"状态 .

    • 使用这个新的"temp"连接开始从我们的客户端发送消息 .

    • 确保连接处于"blocked"状态 .

    • Without eliminating 资源报警,重启RabbitMQ节点 .

    • "temp"连接本身就在这里!尽管没有启用自动恢复功能 . 它继续发送心跳,因此服务器没有关闭它 .

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

相关问题