GitLab内存占用过高怎么办？低配服务器优化实战指南

你是不是也遇到过这种场景高高兴兴在服务器上装了个 GitLab 社区版结果没几天就发现云监控报警内存直接红到 95% 以上SSH 敲命令都开始卡顿。如果你用的是宝塔面板那感受会更明显——软件商店里点一下装完本来想的是“挺简单的”结果top一看满屏全是bundle开头的进程CPU 和内存双双拉满。别慌这问题我踩过坑也彻底解决过。GitLab 社区版确实是个吃资源的大户但它不是“无药可救”。这篇就来聊聊如何用最直接的方法把资源占用降下来让 GitLab 在低配服务器上踏实跑起来。尤其是宝塔安装版包括 RPM 安装版和 Docker 安装版我会把配置文件在哪、怎么改、改完怎么验证一步步讲清楚。适合正在被 GitLab 内存问题折磨、又不想花大钱升级服务器的朋友。1. 问题现场GitLab 社区版和 bundle 进程的“内存狂欢”1.1 先判断你是不是也中招了如果你还没确认自己的 GitLab 是不是真的“资源占用过高”先别急着改配置我建议花一分钟看一下当前机器的实际状态。登录服务器后跑两条命令free -m ps aux --sort-%mem | head -20第一条看内存总量和剩余量第二条看当前占用内存最高的前 20 个进程。如果你看到的结果类似这样内存几乎被吃光、Swap 已经用了一大半、进程列表里前 10 名有好几个都是bundle开头那恭喜你和我要说的是同一个问题。还有一种更严重的表现GitLab 页面访问时好时坏偶尔直接报 502。之前我遇到过一台 2 核 4G 的机器装完 GitLab 社区版后连宝塔面板登录都费劲最后发现是 GitLab 里面的监控组件、Sidekiq 并发线程把内存吃满了系统触发了 OOM Killer随手干掉了一个关键进程GitLab 自然就瘫了。1.2 bundle 进程到底是什么为什么“成群结队”第一次看到大量bundle进程很多人会怀疑是不是服务器被人入侵了毕竟正常情况下谁会起一堆名字一样的进程。别紧张GitLab 是用 Ruby on Rails 开发的bundle exec是运行 Ruby 应用最常见的命令所以你在进程列表里看到的bundle进程本质上就是 GitLab 自身在运行。具体来说你看到的 bundle 进程主要分两类一类是 Puma老版本叫 Unicorn这是 GitLab 的 Web 应用服务器。它负责处理你访问 GitLab 页面、提交代码、操作仓库这些前端请求。Puma 为了提升并发处理能力会启动多个 worker 进程每个 worker 都独立加载一份完整的 Rails 代码内存占用自然不小。默认情况下worker 数量等于服务器 CPU 核心数2 核就是 2 个 worker4 核就是 4 个每个 worker 动辄吃掉几百兆内存。另一类是 Sidekiq这是 GitLab 的后台任务处理器。它负责跑各种异步任务比如发送通知邮件、更新仓库信息、解析 CI 构建日志等。Sidekiq 是单进程多线程架构但默认并发数很高通常有 25 个线程。每个线程虽然单独占用内存不大但叠加起来也非常可观。除了这两类核心进程GitLab 还自带了一套监控全家桶Prometheus、Grafana、Alertmanager 以及各种 exporter。如果是宝塔安装版这些组件大多默认启用加起来能轻轻松松吃掉 800MB 到 1GB 内存。所以你会发现 GitLab 一开始就很重。这并不完全是安装方式的问题而是 GitLab 本身的架构设计决定了它需要大量内存。我们优化的思路很简单去掉不用的组件、降低核心进程的资源配额让它“瘦”下来。2. 瘦身第一刀关闭监控全家桶杀掉最吃内存的一批进程2.1 为什么监控组件成了资源黑洞很多人不知道GitLab 社区版默认会装一整套 Prometheus 监控体系。它的想法很好让你在 GitLab 后台直接看各种性能指标比如请求延迟、数据库连接数、磁盘 IO 等等。但问题是这套监控对你的日常代码托管需求几乎是可有可无的而它背后的代价非常高昂。Prometheus 本身要常驻内存Grafana 要跑一个 Web 服务加上 node_exporter、redis_exporter、postgres_exporter、gitlab_exporter 这些采集器每一个都是独立进程。在低配服务器上这些监控组件加起来占的内存可能比 GitLab 主应用还夸张。我之前在一台 4G 内存的机器上测试过关闭监控全家桶之前free -m显示已用内存约 3.6GB关闭并重启 GitLab 之后内存降到 2.4GB 左右省出了一个多 GB 的空间。这个优化可以说是“刀刀见血”。有朋友会担心关了监控之后GitLab 出问题了怎么排查实际上你还有宝塔面板的监控、云厂商的监控和日志实在不行还有运维自建的告警系统。GitLab 自带监控关掉对本地的代码托管和 CI/CD 功能没有任何影响只是后台的“监控”菜单里看不到数据了属于正常现象。2.2 关闭监控组件的具体配置在 GitLab 主配置文件/etc/gitlab/gitlab.rb宝塔 RPM 安装版和新版 Docker 安装版基本都是这个路径中追加或取消注释以下几行prometheus_monitoring[enable] false alertmanager[enable] false node_exporter[enable] false redis_exporter[enable] false postgres_exporter[enable] false gitlab_exporter[enable] false grafana[enable] false部分新版本 GitLab 中Prometheus 相关的开关也可能写作prometheus[enable] false我不太建议两个都写你先根据自己的 GitLab 版本打开gitlab.rb文件搜索一下看注释里到底支持哪种写法。如果两种开关都存在那就两个都加上反正最终目的就是让这些组件全部退出历史舞台。改完之后需要先让配置生效gitlab-ctl reconfigure gitlab-ctl restart如果你是 Docker 安装的 GitLab且配置文件挂载在宿主机比如宝塔面板常见的/www/gitlab/config/gitlab.rb那你就在宿主机上改完再进容器内执行配置生效docker exec -it gitlab gitlab-ctl reconfigure docker exec -it gitlab gitlab-ctl restart执行完reconfigure如果输出一大段日志最后没有报错基本就说明配置没写错。之后再看ps aux | grep -E prometheus|grafana|exporter如果相关进程已经消失这步优化就成功了。3. 控制 Puma 与 Sidekiq让核心应用“吃”得少一点3.1 Puma/Unicorn调整 Rails 进程数和线程数关掉监控只是第一步真正决定 GitLab 内存占用上限的是 Puma 和 Sidekiq 的并发配置。先看 Puma。在gitlab.rb中Puma 相关的配置长这样puma[enable] true puma[worker_processes] 2 puma[min_threads] 1 puma[max_threads] 4worker_processes是 Puma 启动的 worker 进程数每个 worker 都是一个独立的 Ruby 进程。一般来说worker 数量等于 CPU 核心数是最佳实践但如果你的服务器只有 2 核 4G 内存我建议直接设为 2不要再往上加。如果服务器只有 1 核 2G 内存那就只能委屈它设成 1 了。min_threads和max_threads控制每个 worker 内部的线程数。线程越多单进程并发处理能力越强但内存也会相应增加。低负载的个人或小团队使用场景下把max_threads从默认的 4 降到 2 是一个非常有效的省内存操作。我自己的经验是2 个 worker、每个 worker 带 2 个线程足够支撑七八个人的小团队日常使用。需要特别注意版本差异。如果你用的是老版本的 GitLab11.x 之前Web 服务器不叫 Puma而是 Unicorn。这时候你要改的是unicorn[enable] true unicorn[worker_processes] 2不同版本的字段略有差异改之前最好确认一下当前 GitLab 版本。在服务器上执行cat /opt/gitlab/version-manifest.txt | head -n 5看到gitlab-ce 15.x这种版本号就说明是新版用 Puma 配置如果是比较老的版本用 Unicorn 配置。3.2 Sidekiq降低后台任务并发Sidekiq 的默认并发数同样是 25这个数值对低配服务器实在太不友好了。Sidekiq 虽然只有一个进程但内部维护着很多并发线程每个线程都要预分配栈空间并且会加载一些业务上下文并发越高内存占用越多。在gitlab.rb中Sidekiq 的并发配置有两种写法# 新版 GitLab sidekiq[max_concurrency] 10 # 老版 GitLab sidekiq[concurrency] 10个人使用或小团队场景我建议直接设成 5 到 10别超过 10。可能有人担心并发低了后台任务会不会积压实测下来GitLab 的后台任务比如发邮件、更新仓库统计绝大多数时间都在队列里等待真正需要同一时间并发执行的场景非常少。5 个并发足以应付日常负载积压的概率很低。如果你开过很多项目仓库并且经常跑 CI 构建可以适当调高一些比如 10。但记住一个原则内存优先并发够用就行。你完全没必要让一个 4G 内存的服务器为了并发 25 的 Sidekiq 疲于奔命。改完 Puma 和 Sidekiq 之后别忘了再次让配置生效gitlab-ctl reconfigure gitlab-ctl restart执行重启后用ps aux | grep -E puma|sidekiq|bundle看一下进程规模正常情况下进程数量会明显减少每个进程的内存占用量也会降下来。4. 宝塔安装版实战配置文件在哪、怎么改最稳4.1 先分清你是 RPM 版还是 Docker 版在宝塔面板里安装 GitLab常见的有两种情况改动配置的方式完全不同。第一种是通过宝塔软件商店安装的 GitLab 社区版RPM 包安装。这种情况和官方 Linux 安装包是同一套逻辑核心配置文件就在/etc/gitlab/gitlab.rb。你想改什么参数直接改这个文件然后执行gitlab-ctl reconfigure和gitlab-ctl restart。第二种是通过宝塔的 Docker 方式安装的 GitLab宝塔软件商店里很多一键安装应用其实是帮你拉了个 Docker 镜像再跑容器。这时候配置文件通常不在宿主机默认路径而是在你挂载目录里。宝塔常见路径可以是/www/gitlab/config/gitlab.rb当然具体要看安装时怎么配置的。区分方法很简单在服务器上执行docker ps --format {{.Names}} {{.Image}} | grep -i gitlab如果有输出说明你用的是 Docker 版。再看宿主机上是否存在/etc/gitlab/gitlab.rbls -l /etc/gitlab/gitlab.rb如果这个文件存在说明容器把配置目录挂载到了宿主机/etc/gitlab如果不存在就说明配置在容器内部或者挂载到了其他目录。你可以通过docker inspect gitlab查看挂载信息找到真正的配置文件路径。这里我想强调一点Docker 版改完配置后一定要在容器内执行reconfigure而不是在宿主机上执行。宿主机大概率没有安装gitlab-ctl命令。正确流程是改宿主机的挂载配置文件 →docker exec -it gitlab gitlab-ctl reconfigure→ 重启 gitlab 容器。4.2 一套可抄作业的完整优化配置我直接给你贴一份我觉得比较省心的优化配置。这份配置以“2 核 4G 内存、个人或小团队使用”为基准你根据自己的机器配置适当调整即可。直接在/etc/gitlab/gitlab.rb末尾追加# 资源优化配置 # 外部访问地址改成你的 IP 或域名端口避开宝塔常用端口 external_url http://你的服务器IP或域名:8080 # Puma 进程与线程 puma[enable] true puma[worker_processes] 2 puma[min_threads] 1 puma[max_threads] 2 # Sidekiq 并发 sidekiq[max_concurrency] 10 # 关闭监控组件 prometheus_monitoring[enable] false alertmanager[enable] false node_exporter[enable] false redis_exporter[enable] false postgres_exporter[enable] false gitlab_exporter[enable] false grafana[enable] false # 调低 PostgreSQL 内存占用 postgresql[shared_buffers] 128MB注意几点。第一external_url中的端口我建议改成 8080 或者其他未占用的端口。因为宝塔面板自带的 Nginx 默认占用 80 和 443GitLab 如果也监听 80两者必然冲突。第二postgresql[shared_buffers]默认是 256MB调小到 128MB 能省内存但不要再往下调了否则数据库性能会明显下降。第三puma[worker_processes]不要设置成 0GitLab 会直接拒绝启动最少也是 1。修改完保存退出执行gitlab-ctl reconfigure gitlab-ctl restart然后打开浏览器访问http://你的服务器IP或域名:8080确认 GitLab 能正常打开再继续。4.3 端口冲突与宝塔反向代理如果你实在不想用 8080 端口想让团队直接通过 80 端口访问 GitLab又不想停掉宝塔 Nginx那你可以用反向代理来“曲线救国”。具体操作是GitLab 这边继续监听 8080然后在宝塔面板中新增一个站点域名指向你的 GitLab 域名或服务器 IP然后在站点设置里配置反向代理把请求转发到http://127.0.0.1:8080。宝塔自带的“反向代理”功能可以直接填写 URL生成配置。不过需要注意GitLab 对Host请求头有严格校验如果反向代理没有把Host透传过去页面会报“Host is not allowed”的错误。宝塔自动生成的反向代理配置有时候会遗漏这个问题。你可以手动编辑 Nginx 配置在location /块里加上proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;配置完 Nginx 后先重启 Nginx再刷新 GitLab 页面。如果还报错检查一下 GitLab 的external_url是否已经改成外部访问用的域名或 IP不能让 GitLab 以为自己在 8080 端口上对外服务而实际入口是 80 端口这样也会引发各种跳转错误。5. 改完配置怎么验证内存、进程数、服务健康一次看明白5.1 重启之后必须做的检查配置改完、服务重启后不要急着关掉终端。先做一轮基础检查确保 GitLab 确实“活”了并且资源占用真的下来了。第一查看服务组件状态gitlab-ctl status正常情况下你应该看到run: gitlab-workhorse、run: puma、run: sidekiq等大多数组件都是run状态。如果某个组件显示down比如down: puma那说明配置有问题得回头查reconfigure的日志。第二查看内存和进程占用free -m ps aux --sort-%mem | head -15 ps aux | grep bundle | wc -l重点看free -m里的available列比优化前明显多出一大截就说明生效了。再看进程列表排在最前面的几个进程是不是已经不再是 bundle 或 prometheus。第三访问验证。浏览器打开你的 GitLab 地址能正常显示登录页、能登录进去、能创建一个测试项目那这次优化就算成功了。如果打不开先看是不是 502再看服务状态一般都能定位到问题。5.2 优化前后对比参考我拿自己踩过坑的一台 2 核 4G 服务器做了个简单对比数据大致如下你可以当作参考指标优化前优化后内存占用3.6GB / 3.8GB2.3GB / 3.8GBSwap 使用1.2GB基本不涨bundle 进程数十几个六个左右Puma worker2默认高线程2低线程Sidekiq 并发2510Prometheus 系列进程6~8 个0 个GitLab 页面响应卡顿、偶发 502流畅当然不同机器、不同 GitLab 版本、不同仓库数量都会影响具体数值但整体趋势是一致的关闭监控组件 降低并发立竿见影。5.3 内存还是不够Swap 补位即便做了上述优化如果你只有 2G 内存GitLab 还是可能捉襟见肘。这就要用到 Swap 交换空间了。Swap 相当于把磁盘的一部分当成内存来用虽然速度慢但至少能避免系统因为内存耗尽而 OOM。配置方法也很简单。宝塔面板的“软件商店”里有现成的 Swap 插件点一下就能创建并挂载 2G 或 4G Swap。如果你更习惯命令行操作可以这样做fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 | tee -a /etc/fstab执行完后用free -m查看Swap 这一行会显示你刚创建的大小。我建议 2G 内存的机器至少配 4G Swap4G 内存的机器配个 2G Swap 做兜底就行。Swap 不是银弹它只能解决“内存不够导致进程被杀”的问题如果内存持续被占满你会感受到明显的磁盘 IO 卡顿所以核心思路仍然是尽量压低 GitLab 本身的资源占用。6. 常见问题与排查技巧实录6.1 改完配置 GitLab 起不来了这是最让人崩溃的场景但大多数时候原因很简单基本都是配置文件写错了。最常见的问题是puma[worker_processes] 0或者重复定义了同一个参数且后一个覆盖了正确的值。遇到 GitLab 起不来先看reconfigure的输出日志gitlab-ctl reconfigure 21 | tail -50如果有红字报错基本就是 Ruby 语法错误。找到报错位置把那一段代码删掉或修正再重新reconfigure。如果没有报错但服务仍然起不来再看gitlab-ctl status gitlab-ctl tail pumatail命令会输出对应组件的实时日志看到里面的异常堆栈就能定位到真正原因。根据我的经验90% 的启动失败都是因为在gitlab.rb里写了太多个人的“灵魂配置”互相之间产生了冲突。解决思路永远是最小化改动一次只改一类参数改完立刻验证。6.2 监控页面没数据了关闭 Prometheus 和 Grafana 之后GitLab 后台“监控”菜单里会显示“无数据”或直接报错这是预期结果不是故障。如果你后续又需要监控数据可以重新启用这些组件然后在 gitlab.rb 里把之前的false改回true或直接注释掉再执行reconfigure和restart就能恢复。不过说实话对小团队来说宝塔面板自带的 CPU、内存、磁盘监控已经足够日常巡检用了GitLab 自带监控更多是一个高级运维功能开了不仅占资源看的时间也不多。6.3 进程看着少了内存还是慢慢涨这种情况通常不是 GitLab 本身的问题而是仓库越来越多、后台任务越来越重导致 Sidekiq 积压了队列。你可以先用 GitLab 后台的“管理区 → 监控 → 后台任务”页面看看队列积压情况也可以直接在服务器上观察gitlab-rails runner puts Sidekiq::Queue.all.sum { |q| q.size }如果积压任务比较多说明并发太低了可以适当把sidekiq[max_concurrency]调高到 15 或 20同时观察内存涨幅能否接受。另外GitLab 的日志也会不断增长磁盘满了会进一步拖慢系统建议定期清理/var/log/gitlab/下的旧日志或者配置 logrotate。6.4 个人/小团队服务器配置建议最后附一份我实际用过的配置参照表针对不同规模的服务器参数怎么给比较合适服务器配置Puma workerPuma max_threadsSidekiq 并发Swap适用场景1 核 2G1254G个人学习、仓库数少2 核 4G22102G~4G小团队 10 人以内4 核 8G3415可选团队 20 人左右4 核 16G 及以上默认即可默认即可默认即可可不要团队扩容、CI 频繁不要看到一个参数就直接抄最好结合自己的仓库数量、团队成员数量、CI/CD 使用频率来定。少用两个并发换来的是系统稳定这笔交易很划算。另外补充一个容易忽略的点如果服务器内存确实只有 2G就算参数再极致GitLab 跑起来也会比较吃力。建议这种配置只做学习用不要承载重要生产仓库。如果真的需要低资源占用的代码托管工具可以考虑 Gitea 之类的轻量方案。当然那又是另一个故事了不在本次讨论范围内。