GitLab CI/CD作业持续Pending状态的运行机制与等待时长优化方案

GitLab Runner 采用长轮询模式拉取作业，核心逻辑如下：

• Runner启动后会持续向GitLab服务端的/api/v4/jobs/request接口发起POST请求，请求会保持挂起状态，直到有匹配标签、符合并发限制的作业分配给当前Runner，或是达到服务端长轮询超时阈值才返回响应。
• 正常链路下，若当前无待分配作业，Runner收到服务端超时响应后会立刻发起下一轮轮询，作业触发后通常10-30秒即可被Runner拾取启动。

重启Runner后作业立刻启动、平时等待数分钟的现象，本质是长轮询连接被中间网络设备静默截断，Runner未感知连接失效，持续等待无效连接的响应直到TCP层超时才触发重连。AWS VPC安全组、NAT网关默认的空闲TCP连接超时为350秒，且丢弃空闲连接时不会主动向两端发送断开通知，刚好匹配数分钟等待的故障特征。

所有配置修改完成后执行gitlab-runner restart即可生效，调整项如下：

Runner 配置文件调整 #

Runner配置文件默认路径为/etc/gitlab-runner/config.toml：

• 调整全局参数concurrent：匹配EC2实例可承载的最大并发作业数，避免因并发上限导致的作业排队。
• 调整全局参数check_interval：默认值为3，代表多并发拉取协程之间的请求间隔偏移，单位为秒，保持为1即可，无需设置过大。
• 调整单Runner段参数request_concurrency：代表单个Runner同时发起作业拉取请求的并发数，默认值为1，若全局concurrent值大于2，可将该值设置为全局并发数的1/2，避免单请求阻塞拉取流程。
• 调整单Runner段参数client_timeout：设置为"60s"，强制客户端侧HTTP请求60秒主动超时重连，该值小于AWS侧默认350秒的空闲连接超时，可避免连接被静默截断后长时间无感知等待。
• 开启TCP keepalive探测：在Linux系统层面修改sysctl参数，编辑/etc/sysctl.conf添加以下配置，执行sysctl -p生效，避免长连接被中间设备判定为空闲丢弃：

  net.ipv4.tcp_keepalive_time = 60
  net.ipv4.tcp_keepalive_intvl = 10
  net.ipv4.tcp_keepalive_probes = 3
  

AWS 侧配置优化 #

• 若EC2通过NAT网关访问公网，将NAT网关对应路由的空闲TCP超时调整为90秒，和Runner侧的60秒客户端超时适配。
• 无需额外调整安全组规则，TCP keepalive探测包会定期产生流量，避免安全组截断连接。

注：若配置后仍存在偶发等待，可检查Runner标签是否和作业标签完全匹配、Runner是否存在离线缓存异常，标签不匹配导致的Pending不会在重启Runner后消失，和当前故障特征不符，可优先排查链路连接问题。

内容的提问来源于stack exchange，提问作者Arnold Zahrneinder