GitLab Runner互等问题求助：同服务器不同项目Runner阻塞

API 探路者

2026-7-11

同一服务器上GitLab Runner互斥运行的常见原因

Runner并发数配置限制：检查服务器上GitLab Runner的全局配置文件/etc/gitlab-runner/config.toml，如果concurrent参数设为1，意味着整个服务器同一时间只能运行1个CI Job；另外每个Runner自身的limit参数如果设为1，也会限制该Runner只能处理1个Job，导致其他Runner的Job排队。
共享资源独占冲突：两个Runner的Job依赖同一独占型资源，比如同一个端口、本地锁文件、数据库独占连接，或者使用了未做隔离的本地工作目录。比如两个Job都要写入同一个本地文件，或者抢占同一个GPU设备，后启动的Job会因无法获取资源而进入等待状态。
Shell执行器的串行特性：如果两个Runner都使用shell执行器，默认情况下同一系统用户的Job会串行执行——因为Shell环境是共享的，前一个Job没结束，后一个无法启动。要并行的话，要么给shell执行器配置concurrent参数，要么改用docker、docker-compose这类自带环境隔离的执行器。
CI/CD资源组限制：如果项目的.gitlab-ci.yml中给Job设置了resource_group，同一资源组下的Job无论分配到哪个Runner，同一时间都只能运行一个。这种配置是为了防止并发操作同一资源（比如部署到同一服务器），会导致其他Runner的同组Job等待。
服务器资源耗尽：Runner A的Job占用了服务器大部分CPU、内存或磁盘IO，系统无法为Runner B的Job分配足够资源，导致Job卡在等待状态。可以用top、free -m、iostat等命令查看服务器资源使用情况。
CI配置的依赖或标签限制：如果Job配置了needs字段，依赖另一个未完成的Job，会强制等待；或者tags设置过于严格，导致Job只能分配到特定Runner，而该Runner被占用时就会排队。