直接调优concurrent参数不能破除多租户并发构建排队瓶颈，它仅控制排队深度；真正关键是根据CPU核数（如16核设10~12）、内存及job资源占用，在资源约束下设定最适并发值，并通过limit实现租户级软隔离，结合监控持续微调。

直接调优 concurrent 参数不能“破除”多租户并发构建的排队瓶颈，它只是控制排队深度的开关。真正破除瓶颈的关键，是让这个参数值既不卡住开发，也不压垮机器——也就是在资源约束下，把并发数设成最合适的那个数字。

看清 concurrent 的真实作用域

concurrent 是 config.toml 文件最顶层的全局硬上限，它限制的是单个 Runner 实例能同时运行的 job 总数，不管这些 job 来自多少个项目、多少个团队（即多租户场景）。它不是按租户分配的配额，也不是建议值，而是一道不可逾越的闸门。

• 设为 8，就永远不可能有第 9 个 job 同时执行，其余全部排队
• 这个值对所有执行器（Docker、Shell、Kubernetes）都生效
• 修改后必须重启 Runner 容器或服务才能生效，热加载不支持

用硬件资源反推合理并发值

盲目设高会引发 CPU 过载、内存 OOM 或磁盘 I/O 阻塞；设低则导致大量 job 在队列中空等。推荐以 CPU 核心数为基准起点，再留出系统余量：

• 16 核服务器 → 初始建议 concurrent = 10~12（预留 2~4 核给系统进程、GitLab 通信、日志收集等）
• 每个典型 CI job 平均占用约 1.5~2 核 → 可用核数 ÷ 1.8 ≈ 合理并发上限
• 内存同样关键：若单个 job 常驻内存 1.2GB，64GB 主机最多支撑约 30~35 个并发，但需与 CPU 协同判断，取两者中更紧的那个约束

配合 limit 实现租户级软隔离

虽然 concurrent 是全局的，但你可以在每个 Runner 实例的 [[runners]] 区块里加 limit，实现逻辑上的租户分流：

魔乐社区

魔乐社区是一款面向人工智能开发者的模型、数据、工具和应用协同社区。

下载

• 部署多个 Runner 实例（例如按环境或业务线命名），各自绑定不同标签（如 tags = ["backend", "prod"]）
• 为每个实例设置 limit = 3，表示该 Runner 最多跑 3 个 job
• 全局 concurrent = 12，就允许最多 4 个这样的实例并行工作，避免某类任务独占全部槽位
• 这样既维持了整体吞吐，又防止一个大项目拖慢所有其他租户的构建响应

监控反馈闭环：别只靠经验猜

调优不是一锤定音，而是持续观察 + 微调。重点关注三个指标：

• 平均 job 等待时间：GitLab UI 的 CI/CD → Pipelines 页面可查看，超过 5 分钟说明并发偏紧
• 宿主机资源水位：CPU 持续 >85%、内存 >85% 或磁盘 await >20ms，说明已到临界点
• Runner 日志中的 rejected jobs：出现 “job rejected: runner is busy” 提示，就是 concurrent 或 limit 卡住了

每次调整后观察 1~2 天，优先保证稳定性，再逐步释放并发能力。