Linux GitLab占用内存过高

GitLab 在 Linux 上内存占用过高是常见问题，尤其是默认配置偏向“功能全集”。下面按原因 → 排查 → 优化方案给你一个实用清单，从“立刻能做的”到“根本性的调整”。

一、先确认：是 GitLab 真的内存高，还是被误判？

1️⃣ 查看真实内存占用

free -h
top
htop

重点看：

RES / RSS（实际占用）
buff/cache（Linux 缓存，不是真的占用）
GitLab 进程：gitlab, postgres, redis, puma, sidekiq

GitLab 官方推荐最低内存：

✅ 8 GB（必须）
❌ 4 GB 会频繁 OOM
✅ 16 GB 及以上才舒适

二、GitLab 内存高的核心原因（90% 的原因）

✅ 1. Puma（Web 服务）线程/进程太多

GitLab 默认会按 CPU 核数自动开 Puma worker。

✅ 2. Sidekiq（后台任务）占用高

处理 CI、Webhook、邮件。

✅ 3. PostgreSQL 缓存设置过高

默认按机器内存计算，小机器照样吃。

✅ 4. Prometheus + Node Exporter

监控组件非常吃内存。

✅ 5. GitLab 开了你根本用不到的功能

CI Runner
Container Registry
GitLab Pages
Elasticsearch

三、立刻能做的优化（推荐先做）

✅ 1️⃣ 限制 Puma（最关键）

编辑配置：

sudo vim /etc/gitlab/gitlab.rb

puma['enable'] = true
puma['worker_processes'] = 2   # 默认是 CPU 核数，4 核以下建议 2
puma['min_threads'] = 1
puma['max_threads'] = 2

小服务器推荐：

2 核 4G → worker_processes = 1
4 核 8G → worker_processes = 2

✅ 2️⃣ 限制 Sidekiq

sidekiq['max_concurrency'] = 10

默认是 50，非常浪费。

✅ 3️⃣ 限制 PostgreSQL 内存

postgresql['shared_buffers'] = "256MB"
postgresql['work_mem'] = "8MB"
postgresql['maintenance_work_mem'] = "32MB"

✅ 4️⃣ 关闭 Prometheus（内存杀手）

prometheus_monitoring['enable'] = false

⚠️ 关闭后无法使用内置监控图表。

✅ 5️⃣ 关闭不需要的功能

gitlab_rails['gitlab_ci_enabled'] = false
registry['enable'] = false
pages_external_url = nil
gitlab_pages['enable'] = false

四、让配置生效（必做）

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

五、内存占用对比（优化前后）

场景	内存占用
默认安装	6–10 GB
优化后（8G 服务器）	3–5 GB
最小可用	2.5 GB

六、如果服务器只有 4G 内存怎么办？

❌ 不推荐方案

继续用 GitLab Omnibus（内存杀手）

✅ 推荐方案

换轻量 Git 服务
- Gitea ✅（推荐，仅 100–300MB）
- Forgejo
GitLab 只跑在单独服务器
Docker 限制内存

docker run -m 6g gitlab/gitlab-ee

七、迁移建议（长期）

用户数	建议
< 20 人	Gitea
20–100 人	GitLab + 上面优化
> 100 人	8–16 GB 服务器

八、如果你愿意，我可以帮你：

✅ 根据你的 服务器配置 给出 最优 gitlab.rb
✅ 直接帮你算 还能不能跑 GitLab
✅ 帮你 迁移到 Gitea

你可以直接发我：

服务器内存
CPU 核数
GitLab 版本
是否用 CI / Registry

我可以给你一套“刚好不崩”的配置。