Rabbitmq内存控制，队列已满并且不是分页。连接挂起

Question

我正在测试rabbitMQ，芹菜设置。

在当前的设置中有一个jobqueue（2GB RAM，65GB HD），只有一个工作人员将大量消息推送到队列中（稍后我们将添加一堆工作人员）。当jobqueue达到大约1100万条消息时，连接挂起（很确定这是blocking由于基于内存的流量控制，如http://www.rabbitmq.com/memory.html）。但连接永远挂起，永远不会关闭连接，也不会分页到磁盘。这是不受欢迎的行为 - 导致芹菜工人变成僵尸过程。

在考虑系统可能实际需要的总大小时 - 我们希望队列能够承载10000次这样的负载 - 总共最多约300亿条消息在队列中一次。

下面是一些相关设置：

{vm_memory_high_watermark,0.8}, 
{vm_memory_high_watermark_paging_ratio,0.5}] 

最初，我们改变了vm_high_watermark从1.4至2.8，这使得在队列中更多的消息，但仍然不够。

我们正在考虑当然系统在某些时候需要更多的RAM，虽然在这之前我们想了解当前的问题以及如何处理它。

现在，队列中只有11m任务，它使用2GB RAM的80％，整个系统只使用8GB的磁盘。考虑到我们将vm_memory_high_watermark设置为.8，内存使用情况很有意义。尽管如此，磁盘使用对我来说毫无意义 - 并且表明分页没有发生。为什么不让RabbitMQ分页到磁盘以便让队列增长更多？虽然明显放慢了队列机器的运行速度，但这样可以避免死机 - 并且看起来像是理想的回退行为。 AFAIK这确实是整个分页的重点。

其他说明：

我们确认，连接吊，从那时起已在事实上被封锁41小时（通过检查rabbitmqctl report的连接部分）。根据http://www.rabbitmq.com/memory.html这意味着“流量控制正在发生”。问题是 - 为什么不是将消息分页到磁盘？

其他详情：

的Ubuntu 12.04.3 LTS

的RabbitMQ 3.2.2，二郎R14B04

芹菜3.0.24

的Python 2.7.3

Answer 1

如果您的队列不耐用，没有消息将被分页到磁盘。系统将受可用内存的限制。如果您需要将消息刷新到磁盘，请使用durable=true队列。

而这种设计，有很多的负载，而不是消费信息，是不理想的。 RabbitMQ不是数据库，这些消息是暂时的。如果您需要数据存储，请使用Redis，RDBMS等。