这类问题我又碰上了一次。离线评测和在线问答共用一个 worker 池，晚上跑 2 万条评测时，在线请求 P99 从 1.2 秒涨到 4.8 秒，用户开始反馈输入框转圈很久。
第一反应是「没有按来源打标签，限流和监控都分不开」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。两种流量共用一个队列和同一批 worker；批量任务单条耗时长，占住 worker 不放；自动扩容按总积压触发，在线队列被批量掩盖。
第一件事是按来源统计队列等待与处理耗时
python queue_stat.py --by source --window 24h然后把批量任务拆到独立队列与 worker 组
python -c "print('queues=online,batch')"接着在线队列单独设并发与告警阈值
python -c "print({'online_conc':24,'batch_conc':8})"夜间重跑评测确认在线指标不受影响
python run_eval.py --submit batch --n 20000 --watch online_p99改完先别撤，确认这几项。夜间批量跑满时在线 P99 保持在 1.3 秒以内，批量任务吞吐没有下降，两个队列的积压曲线互不影响。
在线和离线混跑是延迟事故的常见来源，物理隔离队列和 worker 最省事；只靠优先级在同一个池里调度，迟早会互相拖。这类问题最好一次改到位，反复小改反而容易把原因搅混。