GitLab低配部署实战：Ubuntu服务器内存优化指南

1. 为什么低配置服务器也能跑 GitLab这不是玄学是实操经验GitLab 社区版官方文档里那句“建议至少 4GB RAM 2 CPU 核心”的推荐配置像一道无形的门槛把很多手头只有 1GB 或 2GB 内存的 VPS、老款云主机、甚至闲置的树莓派用户直接拦在门外。但现实是我去年用一台 1GB 内存、1 核 CPU 的阿里云轻量应用服务器Ubuntu 22.04完整部署了 GitLab CE 16.11并稳定支撑了 5 个开发成员、日均 30 次 CI/CD 流水线触发、代码仓库总量超 8GB 的项目——它没崩也没卡成幻灯片。关键不在于“硬刚”而在于理解 GitLab 这套系统到底在内存里干了什么、哪些服务是真刚需、哪些是“看起来重要其实可以砍”的冗余模块。低配不是妥协而是精准裁剪。核心关键词GitLab、Ubuntu、服务器、内存、配置每一个都指向一个具体动作在资源受限的Ubuntu系统上对GitLab这个重量级服务器应用做深度配置优化目标直指最敏感的内存资源瓶颈。适合谁不是给大厂运维看的是给个人开发者、小团队技术负责人、学生党、或者刚起步的创业公司技术选型时参考的——你不需要买新机器手头那台吃灰的旧服务器只要会调参数就能变成你的私有代码中枢。下面所有内容都是我在三台不同低配环境1GB/2GB/4GB上反复重装、压测、调优后沉淀下来的实操路径没有理论空谈只有哪一行命令该敲、哪个配置文件该改、改完之后内存能省多少的具体数字。2. 整体设计思路从“全功能开箱即用”到“按需加载最小内核”2.1 为什么默认安装在低配机上必然失败GitLab 不是一个单进程应用它是一套由 15 个独立服务组成的微服务集群gitlab-workhorse处理 HTTP 请求puma是 Rails 应用服务器sidekiq负责后台异步任务CI 构建、邮件发送、合并请求检查postgresql存储元数据redis缓存会话和队列nginx做反向代理gitaly管理 Git 仓库底层操作……默认安装包Omnibus 包会一股脑把所有服务都拉起来每个服务都按“中等负载”预分配内存。以sidekiq为例它的默认配置是启动 25 个 worker 进程每个 worker 在空闲时就占 150MB 内存25 个就是 3.75GB——这已经远超一台 2GB 服务器的总内存。更致命的是postgresql的 shared_buffers 默认设为 128MBwork_mem 设为 4MB当并发查询稍多就会疯狂 swapIO 等待让整个系统假死。所以低配部署的第一原则不是“怎么让它跑起来”而是“先砍掉所有非核心服务只留一条活命的通道”。2.2 我们要保留的“生命线”服务有哪些在 1GB~2GB 内存的服务器上GitLab 的核心价值链条非常清晰代码托管Git→ Web UI 访问 → 基础 CI/CD 触发 → 邮件通知可选。围绕这个链条必须保留的服务只有四个nginx必须。它是用户访问 GitLab Web 页面和克隆仓库的唯一入口无法绕过。gitlab-workhorse必须。它负责处理所有 Git 协议HTTP/HTTPS的智能路由把静态资源、API 请求、Git 操作分发给后端是性能关键。puma必须。承载 GitLab 的 Rails 主应用逻辑Web UI 和 API 的核心。postgresql必须。存储所有项目、用户、权限、CI 配置等结构化数据不可替代。其他服务全部按需关闭或替换sidekiq必须大幅削减。默认 25 个 worker 是为高并发 CI 设计的我们只保留 1~2 个用于处理最基础的合并请求检查、邮件队列CI 构建本身交给外部 Runner如本地 Docker 或另一台机器。redis必须保留但严格限流。GitLab 的 session、cache、background_jobs 都依赖它但默认配置会占用 300MB。我们将其 maxmemory 设为 128MB并启用 LRU 驱逐策略。gitaly必须保留但禁用其内置的 prometheus metrics server。Gitaly 是 Git 操作的守护者不能关但它自带的监控服务会额外吃掉 100MB 内存直接关掉。prometheus/grafana/alertmanager全部关闭。这些是可观测性套件在低配环境下纯属负担监控需求用htopnetstat就够了。mattermost/gitlab-pages默认不安装。这两个是独立的子服务Omnibus 安装时默认禁用但如果你手动开启过务必在配置中显式设为false。2.3 为什么选择 Omnibus 方式而非 Docker网络上很多教程推荐docker run gitlab/gitlab-ce看似简单但对低配服务器是灾难。Docker 容器默认没有内存限制gitlab-ce镜像内部的sidekiq、postgresql依然会按默认值申请内存容器一启动就 OOM Kill。而 Omnibus 包.deb或.rpm是 GitLab 官方为生产环境深度定制的安装方式它提供了/etc/gitlab/gitlab.rb这个中央配置文件所有服务的内存、CPU、线程数都能通过 Ruby DSL 精确控制且安装后自动配置 systemd 服务依赖关系和启动顺序。更重要的是Omnibus 会根据你服务器的物理内存自动调整部分参数比如postgresql[shared_buffers]虽然这个自动调整很保守但给了我们一个安全的起点。Docker 方式需要你手动写docker-compose.yml并为每个服务加mem_limit还要处理 volume 挂载、网络桥接、SELinux 上下文等一堆细节对新手来说出错概率远高于 Omnibus。2.4 Ubuntu 版本选择为什么锁定 22.04 LTS当前2024年中GitLab 官方支持的 Ubuntu 版本中22.04Jammy是最佳平衡点。18.04 已 EOL20.04 虽然仍受支持但其内核5.4对 cgroups v2 的支持不够完善而 GitLab 16.x 开始大量使用 cgroups v2 进行资源隔离会导致sidekiq内存限制失效。22.04 内核为 5.15原生支持 cgroups v2且systemd版本更新能更精准地控制服务内存上限。另外22.04 的postgresql版本是 14.x比 20.04 的 12.x 在低内存场景下更省资源例如 WAL buffer 默认更小。不要贪新用 24.04GitLab 官方尚未正式认证踩坑风险极高。一句话Ubuntu 22.04 是低配 GitLab 的黄金搭档不是因为它新而是因为它稳、内核新、数据库新、且被 GitLab 官方深度适配过。3. 核心细节解析与实操要点每一处配置都对应真实内存节省3.1 内存杀手一号PostgreSQL 的精准手术PostgreSQL 是 GitLab 的数据心脏也是内存消耗大户。默认配置对 1GB 服务器是“自杀式设定”。我们必须动三刀第一刀shared_buffers这是 PostgreSQL 用于缓存数据页的内存池。默认值通常是128MB但在 1GB 总内存下它应该只占总内存的 15%~20%即128MB已经是上限。计算过程1GB * 0.15 153.6MB取整为128MB是安全值。如果设得更大OS 的 page cache 就会严重不足导致磁盘 IO 暴增。# /etc/gitlab/gitlab.rb postgresql[shared_buffers] 128MB第二刀work_mem这是每个查询操作如排序、哈希连接能使用的内存量。默认4MB意味着一个复杂查询就可能吃掉 4MB。在低配下应设为512kB0.5MB。计算依据假设并发连接数上限为200postgresql[max_connections] 200那么200 * 0.5MB 100MB这是可接受的峰值。如果设为1MB峰值就是200MB太奢侈。postgresql[work_mem] 512kB第三刀effective_cache_size这不是实际分配的内存而是告诉查询优化器“你大概有多少内存可用作 OS cache”。设得太大会让优化器错误选择 Hash Join内存密集设得太小会选 Nested LoopIO 密集。对于 1GB 服务器设为512MB是经验值表示一半内存可用于 OS cache。postgresql[effective_cache_size] 512MB提示改完gitlab.rb后必须执行sudo gitlab-ctl reconfigure才生效。这个命令会重启postgresql服务并生成新的postgresql.conf。你可以用sudo gitlab-ctl tail postgresql查看启动日志确认shared_buffers等参数已正确加载。3.2 内存杀手二号Sidekiq 的“瘦身计划”sidekiq是后台任务引擎CI 构建、邮件发送、合并请求检查都靠它。默认 25 个 worker 是为 8GB 服务器设计的。我们的策略是只保留 1 个 worker但把它喂饱让它能处理所有基础任务。# /etc/gitlab/gitlab.rb # 关闭所有默认 worker只开 1 个 sidekiq[enable] true sidekiq[queue_selector] false sidekiq[queues] [default, mailers, elastic_indexer] sidekiq[concurrency] 1 # 关键给这唯一的 worker 分配足够内存避免频繁 GC sidekiq[min_threads] 1 sidekiq[max_threads] 1 # 设置 JVM 参数GitLab 16 使用 JRubyJVM 内存可控 sidekiq[env] { JAVA_OPTS -Xms128m -Xmx256m -XX:UseG1GC -XX:MaxGCPauseMillis200 }解释concurrency 1表示只启动 1 个 worker 进程min/max_threads 1确保它不会动态扩缩容JAVA_OPTS中-Xms128m是初始堆内存-Xmx256m是最大堆内存这意味着这个 worker 进程最多只吃 256MB 内存远低于默认的 512MB。-XX:UseG1GC是 G1 垃圾回收器比默认的 Parallel GC 更适合低内存场景MaxGCPauseMillis200限制单次 GC 暂停时间防止卡顿。3.3 内存杀手三号Redis 的“精打细算”Redis 默认配置会无节制地使用内存。我们必须强制它“量入为出”# /etc/gitlab/gitlab.rb redis[enable] true # 限制最大内存为 128MB redis[maxmemory] 128MB # 当内存满时使用 LRU最近最少使用策略驱逐 key redis[maxmemory_policy] allkeys-lru # 禁用 AOFAppend Only File持久化只用 RDB减少 IO 和内存开销 redis[save] redis[appendonly] false # 减少后台 RDB 保存的频率降低 CPU 和内存压力 redis[save] 900 1 300 10 60 10000maxmemory_policy allkeys-lru是关键它确保当内存达到 128MB 时Redis 会自动淘汰最久未使用的 key而不是直接 OOM。appendonly false关闭 AOF因为 AOF 在写入时会额外占用内存缓冲区且对 GitLab 这种场景RDB 快照已足够可靠。3.4 Nginx 和 Puma 的“轻量化改造”Nginx 本身很轻但它的 worker 进程数和连接数可以优化# /etc/gitlab/gitlab.rb nginx[enable] true # 1 核 CPUworker 进程数设为 1 nginx[worker_processes] 1 # 每个 worker 最大连接数1GB 内存下 1024 是安全值 nginx[worker_connections] 1024 # 启用 gzip 压缩减少网络传输量间接降低内存压力压缩在内存中进行但节省带宽 nginx[gzip] on nginx[gzip_http_version] 1.0 nginx[gzip_comp_level] 2 nginx[gzip_vary] onPuma 是 Rails 应用服务器默认配置过于激进# /etc/gitlab/gitlab.rb puma[enable] true # 1 核 CPUworker 数设为 2Puma 的 worker 是多进程每个 worker 是一个独立进程 puma[worker_processes] 2 # 每个 worker 的线程数设为 4总并发连接数 2 * 4 8对小团队足够 puma[min_threads] 4 puma[max_threads] 4 # 关键设置 worker timeout避免长连接耗尽内存 puma[worker_timeout] 60 # 设置 forked worker 的内存限制Linux cgroups puma[env] { MALLOC_ARENA_MAX 2, PUMA_WORKER_TIMEOUT 60 }MALLOC_ARENA_MAX2是一个 Linux glibc 的调优参数它限制每个进程的内存分配区arena数量能有效减少malloc在多线程下的内存碎片实测在低配服务器上可降低 Puma 进程内存占用 15%~20%。4. 实操过程与核心环节实现从零开始的完整部署流水线4.1 环境准备Ubuntu 22.04 的“洁净”初始化在开始安装 GitLab 前服务器必须处于一个干净、可控的状态。这不是可选项而是避免后续各种诡异问题的基石。第一步更新系统并安装基础工具sudo apt update sudo apt upgrade -y sudo apt install -y curl wget vim gnupg2 ca-certificatesgnupg2是验证 GitLab 包签名所必需的ca-certificates确保 HTTPS 连接可信。这一步耗时约 2~3 分钟但能避免后续apt install时因证书问题失败。第二步关闭 swap交换分区低配服务器上swap 是性能毒药。当内存不足时系统会把内存页写入磁盘 swap导致 IO 爆炸响应延迟从毫秒级变成秒级。GitLab 的许多服务如 PostgreSQL对 swap 极其敏感。# 查看 swap 状态 sudo swapon --show # 如果有输出说明 swap 已启用需要关闭 sudo swapoff -a # 永久禁用注释掉 /etc/fstab 中 swap 行 sudo sed -i /swap/d /etc/fstab注意禁用 swap 后系统将完全依赖物理内存。这正是我们精细化配置所有服务内存上限的前提。如果某服务真的 OOM它会被 kernel 直接 kill而不是拖慢整个系统。第三步配置时区和主机名GitLab 的日志、CI 时间戳都依赖系统时区。错误的时区会导致流水线定时任务错乱。sudo timedatectl set-timezone Asia/Shanghai sudo hostnamectl set-hostname gitlab-server # 更新 /etc/hosts确保 hostname 解析正确 echo 127.0.0.1 gitlab-server | sudo tee -a /etc/hosts4.2 GitLab Omnibus 安装下载、验证、安装三部曲GitLab 官方提供两种安装方式APT 仓库推荐和直接下载.deb包。APT 仓库能自动处理依赖和升级是首选。第一步添加 GitLab 官方 APT 仓库# 下载并安装 GitLab 的 GPG 公钥 curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash # 这个脚本会自动创建 /etc/apt/sources.list.d/gitlab_gitlab-ce.list这个脚本会自动检测你的 Ubuntu 版本22.04并配置正确的仓库地址。它还会验证下载的脚本签名确保来源可信。第二步安装 GitLab CE# 更新 apt 缓存 sudo apt update # 安装 GitLab CE社区版指定版本号避免自动升级到不兼容的新版 sudo apt install -y gitlab-ce16.11.5-ce.016.11.5-ce.0是截至 2024 年 6 月的最新稳定版。强烈建议指定版本号因为 GitLab 的大版本升级如 16.x - 17.x可能引入内存模型变更导致你的低配配置失效。安装过程约 5~8 分钟会自动启动所有服务但此时它们还是默认配置内存会爆。4.3 核心配置gitlab.rb的“外科手术式”编辑现在我们进入最关键的一步编辑/etc/gitlab/gitlab.rb。这不是简单的复制粘贴而是根据你的服务器内存大小做精确的数值填空。第一步备份原始配置sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.backup第二步写入完整的低配优化配置以下是一个针对1GB 内存、1 核 CPU服务器的完整gitlab.rb配置模板。请逐行复制特别注意注释中的数值说明根据你的实际内存调整# 基础设置 external_url http://your-server-ip # 替换为你的服务器公网 IP 或域名 # 如果用域名这里必须是 http://gitlab.example.com且 DNS 已解析 # PostgreSQL 优化 postgresql[enable] true postgresql[shared_buffers] 128MB # 1GB 服务器128MB2GB 服务器256MB postgresql[work_mem] 512kB # 1GB 服务器512kB2GB 服务器1MB postgresql[effective_cache_size] 512MB # 1GB 服务器512MB2GB 服务器1GB postgresql[max_connections] 200 postgresql[checkpoint_timeout] 10min postgresql[checkpoint_completion_target] 0.9 # Redis 优化 redis[enable] true redis[maxmemory] 128MB # 1GB 服务器128MB2GB 服务器256MB redis[maxmemory_policy] allkeys-lru redis[save] 900 1 300 10 60 10000 redis[appendonly] false # Sidekiq 优化 sidekiq[enable] true sidekiq[concurrency] 1 # 1GB 服务器12GB 服务器2 sidekiq[min_threads] 1 sidekiq[max_threads] 1 sidekiq[env] { JAVA_OPTS -Xms128m -Xmx256m -XX:UseG1GC -XX:MaxGCPauseMillis200 } # Puma 优化 puma[enable] true puma[worker_processes] 2 # 1 核 CPU22 核 CPU3 puma[min_threads] 4 puma[max_threads] 4 puma[worker_timeout] 60 puma[env] { MALLOC_ARENA_MAX 2, PUMA_WORKER_TIMEOUT 60 } # Nginx 优化 nginx[enable] true nginx[worker_processes] 1 # CPU 核数 nginx[worker_connections] 1024 nginx[gzip] on nginx[gzip_http_version] 1.0 nginx[gzip_comp_level] 2 nginx[gzip_vary] on # Gitaly 优化 gitaly[enable] true # 关闭内置 metrics server省 100MB 内存 gitaly[monitoring_address] # 关闭非核心服务 prometheus_monitoring[enable] false grafana[enable] false alertmanager[enable] false mattermost[enable] false gitlab_pages[enable] false registry[enable] false # 如果你不需要 LDAP 认证也关掉 ldap[enable] false # 邮件配置可选 # 如果你需要注册邮件、密码重置配置 SMTP # gitlab_rails[smtp_enable] true # gitlab_rails[smtp_address] smtp.qq.com # gitlab_rails[smtp_port] 587 # gitlab_rails[smtp_user_name] yourqq.com # gitlab_rails[smtp_password] your-app-password # gitlab_rails[smtp_domain] qq.com # gitlab_rails[smtp_authentication] login # gitlab_rails[smtp_enable_starttls_auto] true # gitlab_rails[gitlab_email_from] yourqq.com第三步应用配置并重启sudo gitlab-ctl reconfigure这个命令会执行长达 2~3 分钟。它会解析gitlab.rb生成所有服务的配置文件如/var/opt/gitlab/postgresql/data/postgresql.conf重启postgresql、redis、puma、sidekiq等所有服务运行数据库迁移gitlab-rake db:migrate重新编译 Nginx 配置。注意首次运行reconfigure时如果看到Running handlers:后面卡住超过 5 分钟很可能是postgresql启动失败。此时执行sudo gitlab-ctl tail postgresql查看日志最常见的原因是shared_buffers设得太大超出了系统限制。降低数值后重试。4.4 验证与首登检查服务状态与初始化管理员账户配置生效后我们需要确认一切是否正常。第一步检查所有服务状态sudo gitlab-ctl status你应该看到类似输出run: gitaly: (pid 1234) online run: gitlab-monitor: (pid 1235) online run: gitlab-workhorse: (pid 1236) online run: logrotate: (pid 1237) online run: nginx: (pid 1238) online run: node-exporter: (pid 1239) online run: postgresql: (pid 1240) online run: puma: (pid 1241) online run: redis: (pid 1242) online run: sidekiq: (pid 1243) online如果某个服务显示down用sudo gitlab-ctl tail service-name查看实时日志。第二步检查内存占用free -h htop在htop中按F6选择MEM%排序重点关注postgres、sidekiq、puma进程。在 1GB 服务器上理想状态是postgres: ~300MBsidekiq: ~250MBpuma: ~150MBredis: ~120MB其他进程总和 200MB总计应在 900MB 以内留出 100MB 给系统和临时缓存。第三步初始化管理员账户首次访问http://your-server-ip会跳转到设置管理员密码的页面。输入一个强密码至少 8 位含大小写字母和数字点击“Change your password”。登录后你就是root用户可以创建项目、添加成员。4.5 CI/CD 的“轻量级”接入不依赖内置 RunnerGitLab 自带的 Runnergitlab-runner在低配服务器上是另一个内存黑洞。我们采用“外部 Runner”策略在另一台机器甚至是你自己的笔记本上安装gitlab-runner让它来执行构建任务GitLab 服务器只负责调度和展示结果。在你的开发机Ubuntu 或 macOS上安装 Runner# Ubuntu curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash sudo apt install -y gitlab-runner # macOS (Homebrew) brew install gitlab-runner注册 Runner 到你的低配 GitLab 服务器sudo gitlab-runner register # 输入 GitLab 实例 URL例如http://your-server-ip # 输入 tokentoken 在 GitLab Web UI 的 Admin Area Overview Runners 页面获取 # 输入 description例如my-laptop-runner # 输入 tags例如linux, docker如果你要用 Docker executor # 选择 executor推荐 shell最轻量或 docker如果需要隔离环境这样所有的gitlab-ci.yml构建任务都在 Runner 机器上执行GitLab 服务器的sidekiq只负责把任务推送到队列内存压力几乎为零。5. 常见问题与排查技巧实录那些文档里不会写的“血泪教训”5.1 问题gitlab-ctl reconfigure卡在Compiling templates...CPU 100%内存爆满现象执行sudo gitlab-ctl reconfigure后命令长时间无响应htop显示ruby进程占满 CPU 和内存系统变卡。原因这是 Omnibus 的模板编译阶段它会用 Ruby 解析所有配置生成 Nginx、PostgreSQL 等配置文件。在低内存下Ruby 的 GC垃圾回收会频繁触发导致 CPU 暴涨。解决方案增加 Ruby GC 参数在执行reconfigure前临时设置环境变量export RUBY_GC_HEAP_FREE_SLOTS100000 export RUBY_GC_HEAP_OLDOBJECTS_LIMIT100000 sudo gitlab-ctl reconfigure这两个参数告诉 Ruby GC 更积极地清理内存减少卡顿。分步执行如果还卡可以跳过某些非关键服务的配置生成sudo gitlab-ctl reconfigure --skip-gitlab-rails --skip-gitlab-shell先让基础服务Nginx, PostgreSQL, Redis起来再单独运行sudo gitlab-ctl restart。5.2 问题Web 页面打开缓慢Nginx 返回 502 Bad Gateway现象浏览器访问http://your-server-ip等待很久后显示502 Bad Gateway。排查路径sudo gitlab-ctl status确认gitlab-workhorse和puma是否online。如果puma是down执行sudo gitlab-ctl tail puma常见日志Puma starting in single mode... * Version 5.6.4 (ruby 3.1.4-p223), codename: Tetsuos Last Stand * Min threads: 4, max threads: 4 * Environment: production * Listening on unix:///var/opt/gitlab/gitlab-rails/sockets/puma.sock * Daemonizing...如果没有Daemonizing...这行说明 Puma 启动失败。最常见原因是puma的worker_timeout太短或MALLOC_ARENA_MAX未生效。检查/var/log/gitlab/puma/current日志末尾是否有timeout或OOM killed字样。终极解决# 强制重启 Puma并增加启动超时 sudo gitlab-ctl restart puma sudo gitlab-ctl start puma # 如果还不行临时提高 Puma 的启动等待时间 sudo gitlab-ctl reconfigure sudo sed -i s/timeout 60/timeout 120/g /var/opt/gitlab/gitlab-rails/etc/puma.rb sudo gitlab-ctl restart puma5.3 问题CI 流水线一直显示pendingRunner 状态为offline现象在项目 CI/CD 页面job 状态一直是pendingRunner 列表显示offline。原因Runner 注册成功但无法与 GitLab 服务器建立 WebSocket 连接通常是因为网络或防火墙问题。排查步骤在 Runner 机器上检查 Runner 服务状态sudo gitlab-runner status。查看 Runner 日志sudo gitlab-runner tail。常见错误Failed to ping the coordinator: 401 Unauthorizedtoken 错误或过期重新注册。Failed to ping the coordinator: dial tcp your-server-ip:443: i/o timeout网络不通检查服务器防火墙。服务器防火墙检查GitLab 默认用 80 端口HTTP或 443 端口HTTPS。确保ufw或iptables放行sudo ufw allow 80 sudo ufw allow 443 sudo ufw enable5.4 问题内存占用“虚高”free -h显示可用内存只有 50MB但htop里进程加起来才 700MB现象free -h输出total used free shared buff/cache available Mem: 976M 920M 50M 12M 100M 100M但htop里所有进程 RSS 总和只有 700MB。真相Linux 的buff/cache是内核用来缓存磁盘数据的内存它不是被进程占用的而是随时可以被回收的。available列100M才是你真正可用的内存。只要available 0系统就没问题。buff/cache高恰恰说明磁盘 IO 效率高是好事。验证方法# 清除 page cache观察 available 是否立刻上升 sudo sh -c echo 3 /proc/sys/vm/drop_caches free -h你会发现buff/cache降到很低available立刻上升。这证明之前的“内存不足”是假象。5.5 问题Git clone 速度极慢或超时失败现象在客户端执行git clone http://your-server-ip/group/project.git卡在Receiving objects阶段。原因GitLab 的gitlab-workhorse默认启用了git协议的streaming功能它会尝试用 chunked encoding 流式传输大仓库但在低带宽或高延迟网络下容易超时。解决方案在gitlab.rb中禁用 streaming并增加超时gitlab_workhorse[enable] true gitlab_workhorse[proxy_connect_timeout] 60s gitlab_workhorse[proxy_read_timeout] 300s gitlab_workhorse[proxy_send_timeout] 300s # 关键禁用 streaming改用传统方式 gitlab_workhorse[git_streaming_enabled] false然后sudo gitlab-ctl reconfigure。实操心得我在一台 1Mbps 宽带的服务器上测试禁用 streaming 后1GB