高并发下Netflix Conductor HTTP任务卡scheduled状态优化咨询

3000并行工作流对应约12000个待调度HTTP任务，服务节点、Postgres资源均未打满但任务长期卡在scheduled状态，本质是Conductor调度链路的吞吐瓶颈，和算力无关，核心卡点集中在调度批大小不足、PG锁冲突/扫表慢、线程池配置过小三个方向，任务隔离方案对占比80%的HTTP任务确实没有意义。

• 调整任务扫描（Sweep）核心参数
  Conductor默认调度配置面向低负载场景，批大小、线程数默认值极低，高负载下根本扫不完堆积的scheduled任务：
  • 将conductor.app.sweep-frequency-ms从默认500ms下调到100~200ms，缩短轮询间隔
  • 将conductor.app.sweep-queue-size从默认1000上调到10000~20000，匹配单批次待扫描的任务量级
  • 将conductor.app.sweep-thread-count从默认2~4调整为服务节点CPU核数的1/2，比如16核节点配置8个调度线程，预留一半核数给任务执行逻辑
• 优化Postgres持久层调度逻辑
  资源没打满的场景90%以上是PG锁等待、慢查询导致的，这类等待不会体现在CPU/内存使用率指标上：
  • 打开conductor.postgres.experimentaltaskassignerenabled=true，启用官方为PG实现的无锁任务分配器，替代老版本默认的for update行锁抢任务逻辑，节点数越多优化效果越明显，生产环境无稳定性问题
  • 将conductor.postgres.task-poll-batch-size从默认50上调到500~1000，减少单轮调度和PG的交互次数
  • 给task_in_progress表的status、update_time字段建联合索引，默认部署通常漏建这个索引，扫scheduled状态任务时会走全表扫描，建完后查询速度可提升10倍以上
• 调整HTTP任务执行线程池
  很多场景下任务已经被调度到节点，但没有空闲线程执行，表面看起来是卡在scheduled状态：
  • 将conductor.http.task.thread-pool-size从默认200上调到2000~3000，匹配万级HTTP任务的并发需求
  • 给HTTP任务配置合理的超时时间conductor.http.task.timeout=30000（单位ms），避免慢请求占满线程池阻塞新任务
• 关闭非必要调度开销
  没用到对应特性的话直接关闭，减少调度流程的额外逻辑消耗：
  • 配置conductor.app.event-processing-enabled=false关闭事件处理
  • 配置conductor.app.task-priority-enabled=false关闭任务优先级逻辑

• 拆分调度/执行节点角色
  不要让所有Conductor节点同时跑调度和任务执行逻辑：
  • 部署2~3个专用调度节点，配置conductor.app.worker-enabled=false，仅运行Sweep调度逻辑，不执行实际任务
  • 剩余节点作为专用执行节点，配置conductor.app.scheduler-enabled=false，仅拉取任务执行，不参与队列扫描
    拆分后调度逻辑不会被执行侧的流量波动抢占资源，调度时延会非常稳定。
• 分层替换任务队列存储
  如果并行工作流量级后续还要上涨，直接把运行时任务队列从Postgres切到Redis集群，工作流元数据、执行历史仍然存在Postgres即可。Redis的队列吞吐是Postgres的几十倍，完全不存在行锁等待问题，改造仅需修改存储配置，无需调整业务逻辑。
• 执行节点分组
  虽然HTTP任务占比高不需要做资源隔离，但可以给执行节点打标签配置conductor.worker-group-name=http-worker，让调度节点把HTTP任务优先分到专用节点，系统类任务（SWITCH、JOIN、WAIT等）调度到调度节点执行，避免杂任务抢占HTTP任务的执行资源。

调整后重点观测两个核心指标，压测到3000并行工作流时达标即可确认问题解决：

• conductor_sweep_latency：调度线程扫描队列到投递任务到执行队列的耗时，稳定在100ms以内为正常
• conductor_task_scheduled_to_start_seconds：任务从scheduled状态到实际启动执行的时延，p99值稳定在1s以内为正常

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