我正在测试RabbitMQ,芹菜设置.
在当前设置中,有一个工作队列(2GB RAM,65GB HD),只有一个工作程序将大量消息推送到队列(稍后,我们将添加一堆工作程序).当作业队列达到约1100万条消息时,连接将挂起(很确定这是由于基于内存的流控制而导致阻塞的情况,如http://www.rabbitmq.com/memory.html中所示).但是连接会永远挂起,永远不会关闭连接,也不会分页到磁盘.这是不良行为-导致芹菜工人成为僵尸进程.
在考虑系统可能实际需要的总大小时(我们希望队列能够承受此负载的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分页到磁盘上以允许队列增长更多?虽然显然会减慢队列机器的速度,但这将使它不会死掉,并且似乎是理想的回退行为. AFAIK这确实是分页的重点.
其他说明:
我们确认连接已挂起,并且此后实际上已经阻塞了41个小时(通过检查rabbitmqctl报告的连接部分).根据http://www.rabbitmq.com/memory.html,这表示“正在进行流控制”.问题是-为什么不将消息分页到磁盘?
其他详情:
Ubuntu 12.04.3 LTS
RabbitMQ 3.2.2,Erlang R14B04
芹菜3.0.24
Python 2.7.3
解决方法:
如果队列不持久,则不会将任何消息分页到磁盘.系统将受到可用内存的限制.如果需要将消息刷新到磁盘,请使用持久性= true队列.
而且,这种设计具有很大的负载并且不消耗消息,因此并不理想. RabbitMQ不是数据库,消息是瞬时的.如果需要数据存储,请使用Redis,RDBMS等.
标签:memory,celery,rabbitmq,pagination,python
来源: https://codeday.me/bug/20191122/2057324.html