我在Windows上安装了RabbitMQ Server 3.6.0（我知道是时候升级了，我已经在其他服务器节点上完成了）。
服务器端和客户端均启用心跳（心跳间隔60秒）。
我有一个资源警报（RAM限制），在那之后，我观察到RMQ服务器的TCP连接量增加。
目前有18000连接，而正常数量是6000。
通过管理插件，我可以看到有很多连接0通道，而我们的“正常”连接至少有1个通道。
甚至RMQ服务器重启也无济于事：所有连接都将重新建立。
1.这是否意味着他们真的都活着？
https://github.com/rabbitmq/rabbitmq-server/issues/384中描述了类似的问题，但正如我所看到的，它在v3.6.0中得到了修复。
2.在RMQ Server v3.6.0之前，资源报警后的行为是这样的，我是否理解正确？每一个真实的客户端自动恢复连接，服务器端上可能挂起几个TCP连接？
也许重要的是：我们在服务器和客户端之间有haProxy。
3. haProxy可以解释这种额外的连接吗？也许它阻止客户端接收到一个信号，连接被关闭，由于资源警报？
3条答案
按热度按时间p3rjfoxz1#
1.他们都还活着吗？
只有你能回答这个问题，但我要问-你是如何结束了成千上万的连接？实际上，您应该只为每个逻辑进程创建一个连接。因此，如果您真的有6，000个逻辑进程连接到服务器，这可能是这么多连接的原因，但在我看来，即使在这种情况下，您也远远超出了合理的设计限制。
要进行检查，请查看当您杀死一个逻辑进程时减少了多少连接。
1.在RMQ Server v3.6.0之前，资源报警后的行为是这样的，我是否理解正确？每一个真实的客户端自动恢复连接，服务器端上可能挂起几个TCP连接？
据我所知是的在这种情况下，看起来开发人员遇到了common problem in sockets，这是对断开连接的检测。如果每次有人误解TCP是如何工作的，我都有一美元，我会比贝佐斯更有钱。所以，他们发现有人做了一些错误的假设，当实际上需要读或写来检测死套接字时，开发人员编写代码来（尝试）正确处理它。值得注意的是，这看起来并不是一个非常全面的修复，所以如果概念设计问题已经引入到代码的另一部分，那么这个bug可能仍然以某种形式存在。搜索错误报告可能会给你给予更详细的答案，或者询问支持列表上的某个人。
那要看从理论上讲，haProxy只是一个传递。为了让代理识别连接，必须经过握手，这是一个深思熟虑的过程，不可能无意中发生。关闭连接还需要握手，这可能是haProxy的罪魁祸首。如果haProxy认为连接已断开，并在没有该进程的情况下将其丢弃，那么它可能是一个促成原因。但它本身并没有建立这些新的联系。
mutmk8jj2#
我成功重现了这个问题：最后，这是我们的客户端使用RMQ连接的方式中的一个bug。它创建了1个自动恢复连接（这很好）**，**有时它会创建一个单独的简单连接用于“临时”目的。
重现我的问题的步骤是：
1.使用这个新的“临时”连接开始从我们的客户端发送消息。
1.确保连接处于“阻塞”状态。
1.在不消除资源告警的情况下，重启RabbitMQ节点。
1.“临时”连接本身就在这里！尽管事实上自动恢复没有启用它。它继续发送心跳，所以服务器没有关闭它。
我们将修复客户端始终使用一个且唯一的连接。另外，我们当然会升级Erlang。
z18hc3ub3#
我建议这个用户从Erlang 18升级，它有已知的TCP连接问题-
https://groups.google.com/d/msg/rabbitmq-users/R3700QdIVJs/taDYKI6bAgAJ