2核4G轻量服务器部署GitLab实战:配置调优与CI/CD拆分方案

背景

小团队自建代码托管平台,成本是第一考虑因素。腾讯云轻量2核4G服务器月费不足百元,但GitLab官方推荐最低配置为4核8G。4G内存能否支撑10人日常开发?本文记录在这类配置上部署GitLab的完整流程、调优参数,以及CI/CD Runner分离的可行方案。

实现思路

GitLab是一个"内存密集型"应用------Unicorn处理Web请求、Sidekiq后台任务、Gitaly管理存储、Prometheus监控等进程均占用内存。2核4G下,需做三件事:

精简GiLlab进程:禁用非核心组件(监控、Pages、容器注册表),降低Worker并发数。

分离CI/CD Runner:将Runner部署到另一台廉价机器或使用GitHub Actions,避免与主服务争抢资源。

限制内存使用:控制Sidekiq并发线程和Unicorn工作进程数。

关键步骤

  1. 安装GitLab

采用Omnibus包安装,命令和标准流程相同(curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash,然后 EXTERNAL_URL="https://gitlab.example.com" sudo apt-get install gitlab-ee)。需要注意的是,安装后立即执行 sudo gitlab-ctl reconfigure 会占用较多资源,建议在非高峰时段操作。

  1. 核心配置调优

安装完成后,编辑 /etc/gitlab/gitlab.rb,进行以下调整(典型值来自实际测试,10人团队有效):

将Unicorn工作进程数设置为2(官方默认通常为4,改为2可显著降低内存占用)。

将Sidekiq最大并发数从默认的25降至8~10,避免后台任务瞬间拉满内存。

禁用Prometheus和Node Exporter:prometheus_monitoring'enable' = false、node_exporter'enable' = false。

禁用GitLab Pages:gitlab_pages'enable' = false。

如有容器镜像需求,需禁用Container Registry,也可保留,但会增加内存开销(建议外部单独部署)。

修改后执行 sudo gitlab-ctl reconfigure,查看内存占用:通常从1.8GB降至1.2GB左右。

  1. 调整Swap与内核参数

4G物理内存不足时,适当使用Swap可防止OOM。建议分配2G Swap(腾讯云轻量默认无Swap),通过 dd if=/dev/zero of=/swapfile bs=1M count=2048 && mkswap /swapfile && swapon /swapfile 创建,并写入 /etc/fstab。同时设置 vm.swappiness=10,降低系统对Swap的依赖。

  1. CI/CD Runner分离方案

GitLab Runner默认与GitLab同机,会额外消耗内存(每个并发Job约占用几百MB)。推荐方案A和方案B:

方案A:外部计算 -- 购买腾讯云最低配轻量服务器(1核1G,约30元/月),仅安装Docker和GitLab Runner,注册时指定 --executor docker。主GitLab服务器只做代码托管与MR处理,CI执行完全在Runner节点完成。10人团队日常push/pull,2核4G服务端CPU负载一般在20%~40%,内存长期处于3GB左右,运行稳定。

方案B:使用GitHub Actions -- 如果团队代码已公开或愿意使用公共CI,可将GitLab代码通过webhook推送同步到GitHub私有库,利用GitHub Actions免费额度跑CI,完全省去本地Runner成本。

踩坑记录

OOM Killer频繁杀死Sidekiq -- 首次部署未调优,2核4G服务器启动GitLab后内存飙至3.8GB,正常工作了3天,某次同时接收5个Merge Request后Sidekiq被系统kill。解决方案:降低Sidekiq并发数,并启用Swap后恢复。

Unicorn worker过多导致的502 -- 默认配置下4个worker同时处理Web请求,2核CPU单核高负载时出现频繁502。降为2个worker后问题消失。

监控组件吃掉最后1GB内存 -- Prometheus和Grafana默认会保留大量历史指标数据,4G服务器上禁用后内存释放近800MB。如需监控,单独部署在另一台机器上。

方案对比

|--------------------|----------------|---------------|------------------|
| 方案 | 适用场景 | 优点 | 缺点 |
| 纯代码托管(禁用CI/Runner) | 10人团队只做Git仓库管理 | 2核4G稳定运行,成本最低 | 需要额外Jenkins或外部CI |
| 同机跑Runner(不推荐) | 偶尔跑少量CI Job | 管理简单 | 内存易超限,严重影响Web响应 |
| 分离Runner | 频繁CI/CD需求 | 互不干扰,资源按需分配 | 多一台服务器成本 |

总结

2核4G轻量服务器跑GitLab供10人纯代码托管完全可行------核心在于精准调优和资源隔离。如果一定要在同一个机器上跑CI/CD,强烈建议将Runner部署到独立节点。

相关推荐
光电笑映1 小时前
进程间通信(上):深入理解管道与进程池
linux·运维·服务器
Bigger1 小时前
GitLab-Runner + AI 代码审查服务 + 远程大模型 全套部署运维实战
前端·ci/cd·ai编程
提伯斯6461 小时前
Linux minicom 串口工具超详细使用教程
linux·运维·服务器
艾莉丝努力练剑1 小时前
【Linux网络】网络层IP协议(一)
linux·运维·服务器·网络·tcp/ip·计算机网络·udp
终端行者1 小时前
企业级 Jenkins Pipeline 实战Docker构建前端+Ansible发布
前端·ci/cd·docker·jenkins
Benszen1 小时前
Linux容器简介
linux·运维·服务器
剑神一笑1 小时前
Linux iptables 深度解析:从规则匹配到 NAT 转发实战
linux·运维·服务器
梦想的颜色1 小时前
Docker 入门指南:从零开始掌握容器化技术
运维·服务器·vscode·python·算法·docker·云原生
handler011 小时前
【Linux 网络】:poll/epoll 底层机制与 Reactor 并发模型
linux·运维·服务器·网络·c++·多路转接·多路复用