Ubuntu部署gitlab频繁出现502的问题

问题描述
分析问题
定位原因
解决方法

问题描述

在ubuntu中基于docker部署了gitlab，但是发现网页频繁出现502错误，而且长时间卡死无法正常恢复，只能通过docker restart gitlab才能短暂恢复正常使用。

bash 复制代码

HTTP 502: Waiting for GitLab to boot

It can take up to a few minutes for GitLab to boot completely.

This page will automatically reload every 5 seconds.

创建docker容器时使用的命令：

bash 复制代码

sudo docker run -d \
--hostname localhost \
--shm-size 512m \
--memory 16g \
--memory-swap 24g \
-p 8090:80 -p 10022:22 -p 443:443 \
--name gitlab \
--restart unless-stopped \
-v /.../config:/etc/gitlab \
-v /.../log:/var/log/gitlab \
-v /.../data:/var/opt/gitlab \
gitlab/gitlab-ce:latest

分配的shm-size和memory都非常大，理论上根本不应该不够gitlab使用，而且实际使用频率也很低。

分析问题

运行命令：

bash 复制代码

docker inspect gitlab --format='{{.State.OOMKilled}}'

bash 复制代码

true

这意味着GitLab容器确实是因为触碰了16GB的内存上限，被 Docker 引擎无情地触发了 OOM (Out Of Memory) 机制并强制杀死了核心进程。这正是导致页面卡在 502 并且不断循环重启的直接原因。

但是为什么连16G内存都无法满足gitlab的需求呢？

定位原因

GitLab 的核心 Web 服务是 Puma。默认情况下，Puma 会根据宿主机的 CPU 核心数来自动生成对应数量的 Worker 进程。

每个 Puma Worker 大约会消耗 800MB 到 1GB 的内存。

如果物理机性能很好（比如是一台 16 核或 32 核的服务器），GitLab 就会启动 16 到 32 个 Worker。

单单是 Puma 这一项就会瞬间吃掉 16GB 以上的内存，再加上 PostgreSQL、Redis、Sidekiq 和监控组件，16GB 的 Docker 限制立刻就会被撑爆。

解决方法

在gitlab.rb文件中修改

限制 Puma Worker 数量

bash 复制代码

puma['worker_processes'] = 2

限制并发数：

bash 复制代码

puma['min_threads'] = 4
puma['max_threads'] = 4

刷新配置读取：

bash 复制代码

# 重启容器
docker restart gitlab

# 进入容器内部重新编译配置
docker exec -it gitlab gitlab-ctl reconfigure

# 重启所有 GitLab 服务
docker exec -it gitlab gitlab-ctl restart

修改完成之后，gitlab工作恢复正常，再也没有出现过一段时间后自己卡死无响应的问题。