Question

当我们用芹菜水平扩展时，我们正在经历芹菜的意外行为（增加我们的实例数量）。

我们所执行任务的当前处理时间仅为1小时以上，如果我们扩展到16x worker1和16x worker2或者拥有4x worker1和4x worker2，这就是我们增加工作器实例的时间。

在将指标汇总到prometheus / grafana后，我们可以看到，对samba的磁盘读取，写入和网络不是瓶颈也是工人和经纪人的cpu和ram没有达到最大限度我们也看到任务是批量完成并等待批量任务完成后再开始下一个而不是连续，这会导致在处理再次开始之前暂停一段时间。

我的问题是这种芹菜的预期行为？当我横向缩小时，我希望我的总处理时间减少。

我们的设置：

Rabbitmq Broker 3.6.14 8GB RAM 2CPU  
Celery 4.1.0 (apmq)  
Python application  
2 queues  
8x worker1 8GB RAM 2CPU  
8x worker2 8GB RAM 2CPU  
all in docker containers  
writing to samba share

芹菜配置：worker_prefetch_multiplier = 1

运行命令：

worker1：celery -A node_slave worker -n worker@%h --loglevel=debug --concurrency=2
worker2：celery -A node_slave worker -n worker@%h --loglevel=debug --concurrency=2 -Q queue2
配置测试：gevent，Ofair
处理背景：消息被发送到中央队列，例如queue1，

worker1 将从queue1检索消息并运行应用程序，该应用程序从samba共享（输入）上的目录中检索文件，并将文件转换为特定的文件类型并将其放到（输出）samba共享上 worker1还将异步写入queue2的消息

worker2 对针对queue2中的文件运行应用程序并写入nosql后端。

Answer 1

虽然EC2上的通用SSD磁盘具有可突发的IOPS，但这是我们的问题

增加samba实例上的IOPS并转移到预配置IOPS并增加实例大小为我们提供了更好的吞吐量

芹菜工人的水平尺度导致相同的处理时间

1 个答案: