根本问题是宿主机内存枯竭触发OOM Killer随机终止构建容器，须立即终止内存吞噬进程、为Runner容器设置memory="1536m"和oom_score_adj=-200硬限制、配置2GB Swap并约束/dev/shm大小，再通过docker stats和日志监控Exited(137)信号。
根本问题不在 Runner 本身，而在宿主机内存已濒临枯竭，导致内核 OOM Killer 随机挑中构建容器“清理”。直接调大容器内存限制或重启 Runner 只是掩耳盗铃。必须从节点层切断挤压源头。
立即止血：确认并终止内存吞噬者
先别碰 Docker 或 GitLab，直奔宿主机：
运行
top -o %MEM
或
htop
，按内存使用率排序，一眼揪出吃掉数 GB 的 rogue 进程（常见如失控的 Python 脚本、未设限的 Java 服务、长期驻留的 Puma worker）
重点检查
git
用户下的长时进程：
—— GitLab 自身的 Puma 和 Sidekiq 常年不重启就可能悄悄涨到 10GB+
若发现异常进程，
kill -9 PID
立即终止；若属 GitLab 组件，用
安全重启，释放泄漏内存
堵住漏洞：给 Runner 容器加硬性内存围栏
Runner 启动的每个构建容器都必须自带“生存上限”，否则它会和宿主机其他进程抢内存，必输：
Git
程序猿必备版本控制工具
下载
修改 Runner 配置
，在
区块下强制添加：
这两行作用：第一行锁死容器最多用 1.5GB 物理内存；第二行禁用 swap，避免延迟掩盖压力；第三行降低被 OOM Killer 选中的优先级
切勿留空或写
，那等于交出控制权
根治隐患：为宿主机配 Swap 并约束共享内存
无 Swap 的服务器就像没安全气囊的汽车——内存一触顶，只能硬 crash：
创建 2GB Swap 文件：
永久生效：
同时检查
：很多构建任务（如前端打包、Chrome Headless）会把它撑爆。进 Runner 容器执行
，若超 80%，启动时必须加
参数
长效监控：让挤压苗头无所遁形
靠人工查 top 不可持续，要让系统自己报警：
启用
持续观察 Runner 宿主容器的内存水位
在
中开启日志级别：
，配合
实时盯紧退出码 —— 若频繁出现
，说明围栏已起效，但宿主机仍承压
部署轻量监控如 Netdata 或 Prometheus Node Exporter，对
设置低于 1.5GB 的告警
ps -u git -o pid,%mem,%cpu,cmd --sort=-%mem | head -10sudo gitlab-ctl restart puma/etc/gitlab-runner/config.toml[[runners.docker]]memory = "1536m"memory_swap = "1536m"oom_score_adj = -200memory = "0"sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfileecho '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab/dev/shmdf -h /dev/shm--shm-size=512mdocker stats --no-stream gitlab-runner/etc/gitlab-runner/config.tomllog_level = "debug"journalctl -u gitlab-runner -fExited (137)node_memory_MemAvailable_bytes