直接调优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 天，优先保证稳定性，再逐步释放并发能力。
