request_concurrency是gitlab runner向gitlab拉取任务时的并发请求数，推荐设为2–4以避免tcp连接耗尽；它不控制job执行，仅影响任务获取效率，需配合系统tcp参数调优与监控。
request_concurrency 是 GitLab Runner 用于控制与 GitLab 中心（GitLab instance）之间 HTTP 请求并发数的关键参数，它不直接影响 Job 执行，而是决定 Runner 向 GitLab 查询新任务（如 GET /api/v4/jobs/request）时，最多可并行发起多少个请求。当中心端突发大量待分配 Job（例如批量触发流水线、定时任务集中触发），而 Runner 的 request_concurrency 过高或未合理限制，会导致本地 TCP 连接短时间内密集建立，迅速占满连接队列（如 net.core.somaxconn 或 ESTABLISHED/TIME_WAIT 连接池），引发超时、503、连接拒绝等问题。
理解 request_concurrency 的作用边界
它只约束 Runner 主动向 GitLab 发起的“拉取任务”请求，并不影响：
– 已获取 Job 的实际执行（由 concurrent 和 limit 控制）
– GitLab 主动推送事件（如 webhook）
– Runner 内部 HTTP 客户端复用行为（默认使用 keep-alive，但高并发请求仍会新建连接）
因此，调优目标不是“越快越好”，而是让请求节奏与中心端吞吐能力、本地网络栈承载力匹配。
降低 TCP 队列压力的核心配置建议
-
设为保守值（推荐 2–4）：多数中型团队无需超过 4。即使
concurrent = 16，Runner 也无需同时发 16 个请求去“抢活”。实际测试表明，request_concurrency = 3在千级日 Job 场景下已能保持稳定响应，且显著减少 TIME_WAIT 连接堆积。 -
配合系统级 TCP 参数收紧：确保内核参数支持高频短连接回收：
net.ipv4.tcp_tw_reuse = 1<br>net.ipv4.tcp_fin_timeout = 30<br>net.core.somaxconn = 65535<br>net.ipv4.tcp_max_syn_backlog = 65535
这些需写入/etc/sysctl.conf并执行sysctl -p生效。 - 禁用 tcp_tw_recycle（必须）：该参数在 NAT 环境（如容器、云厂商 VPC）下会导致连接异常丢包，GitLab 官方明确弃用，切勿启用。
配合监控识别洪峰影响
启用 Runner 的 Prometheus 指标端点（默认 http://localhost:9252/metrics），重点关注：
-
gitlab_runner_request_duration_seconds：请求耗时突增说明后端响应变慢或连接排队 -
gitlab_runner_http_requests_total{status=~"5.."}：5xx 错误上升是 TCP 队列溢出或中心限流的直接信号 -
gitlab_runner_jobs_running与gitlab_runner_jobs_pending的差值持续扩大：说明请求虽发出，但未成功拿到 Job，可能卡在连接层
ss -s 或 netstat -s | grep -i "listen.*overflows" 可确认是否存在 listen queue overflow。
进阶：动态适配洪峰的轻量策略
若业务存在强周期性（如每日早 9 点批量 CI 触发），可在 Runner 启动前通过脚本临时调整：
- 低峰期（夜间）：
request_concurrency = 4 - 高峰期前 10 分钟：
request_concurrency = 2+ 增加check_interval = 5（避免频繁轮询加重压力） - 搭配
limit = 1（单 Runner 实例）防止单点过载
gitlab-runner restart），不支持热更新。
