我正在测试一个rabbitMQ，芹菜设置。
在当前设置中有一个作业队列（2GB RAM，65GB HD），只有一个工作人员将大量消息推送到队列中（之后，我们将添加一堆工作人员）。当作业队列达到约1,100万条消息时，连接就会挂起（由于http://www.rabbitmq.com/memory.html中的基于记忆的流量控制，很可能确定这是blocking的情况）。但是连接永远挂起，永远不会关闭连接，也不会分页到磁盘。这是不受欢迎的行为 - 导致芹菜工人变成僵尸进程。
在考虑系统可能实际需要的总大小时 - 我们希望队列能够承受大约10,000倍的负载 - 一次总共最多大约300亿条消息。< / p>
以下是一些相关设置：
{vm_memory_high_watermark,0.8},
{vm_memory_high_watermark_paging_ratio,0.5}]
我们最初将vm_high_watermark从.4更改为.8，这允许队列中有更多消息，但仍然不够。
我们当然认为系统在某些时候需要更多的RAM，尽管在此之前我们想了解当前的问题以及如何处理它。
目前，队列中只有11m的任务，它使用80％的2GB RAM，而整个系统只使用8GB的磁盘。鉴于我们将vm_memory_high_watermark设置为.8，内存使用情况很有意义。但是磁盘使用对我来说没有任何意义 - 并且暗示分页没有发生。为什么不将RabbitMQ分页到磁盘以允许队列增长更多？虽然显然减慢了队列机器的速度，但这会让它不会死 - 而且看起来像是理想的后备行为。 AFAIK这确实是整个分页点。
其他说明：
我们确认连接已挂起，实际上已经被阻止了41个小时（通过检查rabbitmqctl report的连接部分）。根据{{3}}，这意味着“流量控制正在发生”。问题是 - 为什么不将消息分页到磁盘？
其他细节：
Ubuntu 12.04.3 LTS
RabbitMQ 3.2.2，Erlang R14B04
Celery 3.0.24
Python 2.7.3
答案 0 :(得分：3)
如果您的队列不耐用，则不会将任何邮件分页到磁盘。系统将受可用内存的限制。如果需要将消息刷新到磁盘，请使用durable=true队列。
这种设计有很多负载而不消耗消息，并不理想。 RabbitMQ不是数据库，消息是瞬态的。如果您需要数据存储区，请使用Redis，RDBMS等。