Celery处理IO密集型任务时应如何设置worker_concurrency参数？

合理取值确定方法 #

官方文档已经给出基础逻辑，针对你提到的API请求类长IO任务，可以按以下步骤确定取值：

• 先匹配并发模型设置初始值：
  • 如果用默认prefork进程模型，初始值可设置为 CPU核心数 * 4 ~ CPU核心数 * 8，进程等待IO返回的时间占比极高，多开进程可以充分利用空闲CPU资源
  • 如果用eventlet/gevent协程模型，初始值可直接设置为200_{500，你的场景API响应5}10秒，这个区间的初始值适配性更强
• 压测校准最终值：使用生产级流量压测，重点监控任务平均完成延迟、宿主机CPU/内存使用率两个核心指标：如果延迟无明显上涨、CPU使用率低于70%，可以继续上调并发数；如果延迟突然飙升、CPU使用率超过80%，则回退到上一个稳定值即可
• 额外边界限制：需要参考调用的下游API限流阈值，根据利特尔法则，并发数上限不要超过 下游允许的最大QPS * 平均任务响应时间（秒），避免把下游接口打挂

并发数设置过高的额外影响 #

你提到的上下文切换导致CPU负载升高是常见影响，除此之外还有两类常见问题：

• 内存溢出：prefork模型下每个子进程都会复制一份父进程的内存数据，进程数过高会快速占满宿主机内存，触发OOM Kill导致服务直接崩溃；即便是协程模型，每个并发任务也会占用栈内存和上下文对象，开太高同样会触发内存溢出
• 下游服务雪崩：并发数过高会导致对外API请求量突增，超过下游服务承载能力，轻则触发限流返回大量错误，重则导致下游服务不可用，反过来拖垮整个任务队列

worker_concurrency与--concurrency的关系 #

二者完全等价：worker_concurrency是Celery配置文件中的静态配置参数，--concurrency是启动命令行中的动态传参，命令行传参的优先级高于配置文件的静态配置。
使用eventlet协程模型时，由于协程是用户态切换，开销远低于内核态的进程/线程切换，所以可以支持更高的并发数，你示例中设置500是合理的，只要压测指标稳定即可正常使用。

内容的提问来源于stack exchange，提问作者Martin Thoma