我正在测试 rabbitMQ、celery 设置。
在当前的设置中，有一个作业队列(2GB RAM，65GB HD)和只有一个将大量消息推送到队列的工作人员(稍后，我们将添加一堆工作人员)。当作业队列达到大约 1100 万条消息时，连接挂起(很确定这是 阻塞 由于基于内存的流量控制的情况，如 http://www.rabbitmq.com/memory.html )。但是连接永远挂起，永远不会关闭连接，也不会分页到磁盘。这是不受欢迎的行为——导致 celery worker 变成僵尸进程。
在考虑系统实际可能需要的总大小时——我们希望队列能够承受大约 10,000 倍于此负载的大小——队列中一次最多可容纳约 300 亿条消息。
这里是一些相关的设置:
{vm_memory_high_watermark,0.8},
{vm_memory_high_watermark_paging_ratio,0.5}]
我们最初将 vm_high_watermark 从 .4 更改为 .8，这允许队列中有更多消息，但仍然不够。
我们当然认为系统在某个时候需要更多 RAM，尽管在此之前我们想了解当前的问题以及如何处理它。
现在，队列中只有 11m 个任务，它使用了 2GB RAM 的 80%，整个系统只使用了 8GB 磁盘。考虑到我们将 vm_memory_high_watermark 设置为 .8，内存使用是有意义的。不过，磁盘使用对我来说根本没有意义——这表明分页没有发生。为什么 RabbitMQ 不分页到磁盘以允许队列增长更多？虽然这显然会减慢队列机器的速度，但这将使其不会死机——而且似乎是理想的回退行为。据我所知，这确实是分页的重点。
其他说明:
我们确认连接挂起并且实际上已被阻止 41 小时(通过检查 rabbitmqctl 报告 的连接部分)。根据http://www.rabbitmq.com/memory.html这意味着“正在进行流量控制”。问题是——为什么它不将消息分页到磁盘？
其他细节:
Ubuntu 12.04.3 长期支持版
RabbitMQ 3.2.2，Erlang R14B04
celery 3.0.24
python 2.7.3
最佳答案
如果您的队列不是持久的，则不会将任何消息分页到磁盘。系统将受到可用内存的限制。如果您需要将消息刷新到磁盘，请使用 durable=true 队列。
而且这种设计，有很多负载并且不消耗消息，并不理想。 RabbitMQ 不是数据库，消息是暂时的。如果您需要数据存储，请使用 Redis、RDBMS 等。
关于python - rabbitmq内存控制，队列已满，未分页。连接挂起，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21666537/