问题
我有一个RabbitMQ Server作为我的一个系统的队列中心。在最近一周左右的时间里，它的生产商每隔几个小时就会完全停产。
我试过什么
蛮力
停止用户释放锁几分钟，但随后阻止返回。
重启rabbitmq解决了几个小时的问题。
我有一些自动脚本，可以执行丑陋的重新启动，但显然这不是一个正确的解决方案。
分配更多内存
在cantSleepNow's answer之后，我增加了memory allocated to RabbitMQ to 90%。服务器有16GB的内存，而且消息计数不是很高（每天数百万），所以这似乎不是问题。
从命令行：

sudo rabbitmqctl set_vm_memory_high_watermark 0.9

以及
/etc/rabbitmq/rabbitmq.config
：
[
   {rabbit,
   [
     {loopback_users, []},
     {vm_memory_high_watermark, 0.9}
   ]
   }
].

代码与设计
我为所有消费者和生产者使用python。
生产者
生产者是提供调用的api服务器。每当一个呼叫到达时，一个连接被打开，一个消息被发送，连接被关闭。
from kombu import Connection

def send_message_to_queue(host, port, queue_name, message):
    """Sends a single message to the queue."""
    with Connection('amqp://guest:guest@%s:%s//' % (host, port)) as conn:
        simple_queue = conn.SimpleQueue(name=queue_name, no_ack=True)
        simple_queue.put(message)
        simple_queue.close()

消费者
消费者略有不同，但通常使用以下模式-打开一个连接，并等待它，直到消息到达。连接可以长时间打开（例如，几天）。
with Connection('amqp://whatever:whatever@whatever:whatever//') as conn:
    while True:
        queue = conn.SimpleQueue(queue_name)
        message = queue.get(block=True)
        message.ack()

设计推理
使用者始终需要保持与队列服务器的开放连接
生产者会话应该只在api调用的生命周期内有效
这个设计直到一周前才引起问题。
Web视图仪表板
web控制台显示
127.0.0.1
和
172.31.38.50
中的使用者阻止使用者从
172.31.38.50
、
172.31.39.120
、
172.31.41.38
和
172.31.41.38
访问。
Blocking / Blocked queues
系统度量
为了安全起见，我检查了服务器负载。正如预期的那样，负载平均和CPU利用率都很低。
enter image description here
为什么兔子MQ每一个这样的僵局？

最佳答案：

这很可能是由RabByMQ3.3.2的管理模块中的内存泄漏引起的。现在rabbitmq 3.6.3中已经修复了这个问题，并且可以使用here。
该问题本身被描述为here，但在rabbitmq消息板上也被广泛讨论；例如here和here。这也导致了很多奇怪的问题，一个很好的例子是报告的问题here。
作为新版本发布之前的临时修复，您可以升级到新的EST版本、降级到3.6.1或完全禁用管理模块。