check_interval控制runner轮询gitlab获取新job的时间间隔（秒），影响任务发现及时性；高并发时过大易错过job加剧排队，过小则增加服务端负载引发限流，需依gitlab能力平衡设置。
check_interval 控制 Runner 主动向 GitLab Server 发起轮询、检查是否有新 job 的时间间隔（单位：秒）。它不改变 job 执行本身，但直接影响任务“被发现”的及时性——尤其在高并发、短生命周期 job 频发的场景下，这个参数对端到端延迟很关键。
为什么 check_interval 在高并发时特别重要
当大量流水线同时触发（如批量推送、定时同步、PR 集中提交），job 进入队列的速度可能远超 Runner 当前处理能力。此时：
- 若 check_interval 过大（比如 10 秒），Runner 可能连续错过多个新 job，导致部分 job 在队列中“躺平”数秒才被拾取，放大整体排队延迟；
- 若 check_interval 过小（比如 0.5 秒），Runner 会高频发起 HTTP 请求，给 GitLab Server 带来显著额外负载（尤其是认证、权限校验、数据库查询），可能引发 API 限流或响应变慢，反而拖累全局吞吐。
合理设置 check_interval 的核心原则
不是越小越好，而是要在“响应灵敏度”和“服务端压力”之间找平衡点。关键看你的 GitLab Server 能力和 Runner 规模：
- 单台 Runner + 中小规模 GitLab（≤ 500 用户）：默认 3 秒 通常足够，无需调整；
- 多台 Runner（≥ 10 台）集中注册到同一 GitLab 实例：建议统一设为 5–8 秒，避免大量 Runner 同步轮询造成请求毛刺；
- GitLab Server 已启用 Redis 缓存且 CPU/IO 充裕（如 16 核+、SSD 存储、Redis 内存 ≥ 4GB）：可尝试调至 1–2 秒，提升敏感任务（如 deploy 或 lint）的拾取速度；
- 明确观察到 GitLab API 响应延迟升高（
gitlab-rails api_calls指标 > 200ms）或 Nginx 503 错误增多：应立即 增大 check_interval 至 5 秒以上，优先保服务稳定。
一个实用的调优验证方法
不要只看配置数字，要结合可观测性判断效果：
- 在 GitLab Admin Area → Monitoring → Metrics 中，查看
gitlab_runner_job_polling_duration_seconds分位值（P90/P95），理想应 - 对比修改前后
gitlab_runner_jobs_total{status="created"}到status="running"的平均耗时（即“等待拾取时间”），下降明显且无 API 报错，说明调优有效； - 注意：check_interval = 0 是合法值，表示 Runner 使用长连接（HTTP/2 Server-Sent Events）监听 job 事件，理论上零轮询延迟。但需 GitLab ≥ 15.0 且启用了
feature_flags['runner_sse_polling']，生产环境建议先在测试集群验证稳定性。
配合 check_interval 的其他关键项
单独调这个参数效果有限，必须协同优化：
- 确保 concurrent 设置匹配资源：如果 Runner 本身只能并发跑 4 个 job，却把 check_interval 设成 0.5 秒，只是让 5–10 个 job 堆在本地队列里空等，毫无意义；
- 开启 runner cache（如 S3 或 GCS）：减少 job 启动阶段下载依赖的时间，让已拾取的 job 更快进入执行态，间接缓解“感知延迟”；
-
使用 tag 精准分发：避免所有 Runner 轮询全部 job，用
tags: [fast-test]让专用 Runner 只关注相关任务，降低无效轮询量。
