我这台2核4G的服务器之前跑宝塔LAMP一点问题没有结果装上GitLab社区版之后第二天早上起来发现面板都登录不进去了。SSH上去一看好家伙free -h显示内存用了3.6Gtop里刷屏的全是bundle开头的Ruby进程。如果你也遇到过这种场面别急着卸载GitLab这货的“贪吃”是有章可循的而且完全有办法治。这篇文章是我在宝塔环境里反复折腾GitLab社区版CE资源占用优化后沉淀下来的完整方案覆盖了问题诊断、gitlab.rb核心参数调整、宝塔Docker安装版的具体操作以及后续排障。无论你是2G内存的入门机器还是4G/8G的正式服务器照着这套思路调完资源占用基本上能砍掉三分之一甚至一半。标题里提到的bundle进程过多问题就是这次优化的主战场之一下面我会从原理讲到实操尽量让每个人都能照做复现。1. 问题剖析为什么GitLab社区版一跑起来内存就爆1.1 GitLab是全家桶架构不是单个应用GitLab是一个All-in-one架构的产品官方为了让你安装体验简单把一个完整DevOps平台所需的所有服务全打包到了一起。当你运行gitlab-ctl status会看到一大堆服务同时活着PumaRuby Web服务、SidekiqRuby后台任务队列、PostgreSQL数据库、Redis缓存、GitalyGit存储引擎、Nginx反向代理外加Prometheus监控全家桶。这相当于什么感觉就好比你为了吃一碗面把整个厨房的设备都开着灶台、烤箱、微波炉、洗碗机、冰箱全在待机耗电。GitLab的安装包也是这个逻辑每一项服务单独看都不算大但凑在一起基础占用直接奔着2G内存以上去了。宝塔安装版尤其明显因为在宝塔面板里部署时很少有人会去细调GitLab内部的参数默认配置一跑低配机器直接当场阵亡。社区版和企业版的资源占用差异也值得提一句。社区版为了覆盖全场景把所有组件默认全开启而且很多性能优化选项默认不给开。所以如果你只是小团队内部使用社区版默认状态下其实藏着一堆你用不到、却在白白耗电的组件这就是资源占用居高不下的根本原因。1.2 典型的bundle进程爆炸现场bundle进程到底是什么简单说Puma、Sidekiq这些Ruby服务启动时是通过bundle exec来加载Rails环境的。每个Puma worker都会生成一个独立的bundle进程Sidekiq也会有对应的bundle主进程。所以你在top里看到的满屏bundle exec puma、bundle exec sidekiq本质上不是异常进程而是GitLab正常运行时天生的进程形态。问题在于默认配置下这个数量太夸张。我在一台2G内存的服务器上实测过装完GitLab社区版13.x之后什么配置都没动运行不到十分钟内存可用量掉到200M以内页面打开极慢时不时502。用ps aux | grep bundle | wc -l统计bundle类进程数量能达到40到50个。Puma默认起了4个worker每个RSS高达400到500MB光这一项就吃掉近2G内存。Sidekiq默认并发25等于同时开了25个后台线程。这种配置放在8G内存的专用服务器上跑着舒服挤在2G内存的小VPS上自然要出问题。这里要特别提醒一点如果你看到几十个bundle进程千万别试图把它们一个个kill掉那样只会导致GitLab服务崩溃因为它们是核心服务的进程形态。正确做法是调整它们启动的数量和并行度也就是后面要讲的参数调优。2. 动手诊断先看数据再下手别瞎调2.1 三分钟定位资源大户优化之前先别急着改配置。我有过不只一次“凭感觉调完结果更卡”的经历所以现在每台机器都会先做一轮快速诊断三分钟内就能把问题定位清楚。第一步是看整体内存和Swapfree -h重点关注第二行Mem的used和available以及Swap这一行。如果available几乎为0且Swap为0说明系统已经在OOM边缘徘徊了随时可能随机杀进程。第二步看CPU负载uptime如果load average比CPU核心数高出一截比如2核机器load到了4以上说明不光内存紧张CPU也可能被打满了。常见原因是Sidekiq后台任务积压或Prometheus在做数据采集。第三步看进程排行ps aux --sort-%mem | head -30这一步能直接看到排在前面的进程都是谁。在未优化的GitLab上你通常会看到Puma的worker占据前几名每个进程RSS在300到600MB之间紧接着就是PostgreSQL和Sidekiq。注意看这些进程的命令行记录下Puma worker的数量和Sidekiq参数后面调优时就清楚自己该从哪儿下手了。2.2 判断瓶颈在CPU、内存还是IO资源占用过高得先分清是哪一类不然方案容易走偏。内存不够你会看到上面那种内存被榨干、频繁OOM的现象。CPU吃紧你会在top里看到Ruby进程或PostgreSQL进程把CPU顶到100%附近页面响应慢但至少还能打开。IO瓶颈则比较隐蔽具体表现是GitLab页面偶尔卡顿但free和top看着都正常用iostat或者宝塔面板的磁盘监控能发现磁盘读写很高。IO问题在机械硬盘服务器上尤其常见。GitLab的仓库存储、数据库日志、Redis持久化都需要大量随机读写如果用HDD跑GitLab建议优先考虑换SSD或者至少把GitLab的数据目录迁移到SSD上。宝塔用户还有个常见坑把GitLab装在系统盘上而系统盘往往是云服务器里最慢的一块盘。有条件的话最好挂载一块新的数据盘把GitLab的config、logs、data三个目录都放到数据盘上。做个简单的判断总结内存几乎用光优先执行第3节里的Puma、Sidekiq调优并关闭监控组件CPU长期打满重点关注Sidekiq并发和后台CI任务必要时减少Runner数量磁盘IO高优先检查数据盘类型和仓库大小不要把GitLab跑在HDD上3. 核心优化手段改gitlab.rb文件把不用的组件关掉3.1 调整Puma的worker和线程数Puma是GitLab的Web服务进程负责处理HTTP请求。它采用多worker模式每个worker是一个独立的Ruby进程都有自己的内存空间。默认配置下worker数量偏多是小内存机器的第一内存大户。Puma的配置写在/etc/gitlab/gitlab.rb里对应参数是puma[worker_processes]。这里有个经验公式worker数量不要超过CPU核心数内存越紧张越要往低里压。下面的表格是我在几台不同配置机器上验证过的推荐值服务器内存建议worker数建议max_threads2G144G248G4816G可按官方默认8-16我自己的习惯是2核4G的机器设worker_processes 2min_threads 1max_threads 4。这个组合实测下来能同时应对几十个用户的小团队日常使用内存占用比默认配置低很多。修改方式vim /etc/gitlab/gitlab.rb找到或新增以下内容puma[enable] true puma[worker_processes] 2 puma[min_threads] 1 puma[max_threads] 4然后执行gitlab-ctl reconfigure这里说明一下老版本GitLab用的不是Puma而是Unicorn参数名是unicorn[worker_processes]。如果你打开gitlab.rb看到的是unicorn相关配置说明版本较旧直接把unicorn段落改掉也一样。13.0版本以后官方默认使用Puma多数人现在装的都是新版本按Puma配置即可。3.2 限制Sidekiq并发Sidekiq是GitLab的后台任务队列负责处理各种异步任务比如仓库同步、邮件发送、CI状态更新、Webhook回调等等。它默认的并发数很高官方默认情况下max_concurrency可能是25这意味着同时最多有25个线程在跑后台任务。对低配服务器来说这个并发数会导致CPU被后台任务长期占用也加剧内存消耗。建议把并发压到5到10sidekiq[max_concurrency] 5实测中把并发从25降到5之后GitLab页面响应明显变快因为CPU不再被一堆后台任务抢占了。代价是后台任务的处理速度会变慢比如代码推送后的Webhook通知可能要晚个几秒但这对绝大多数小团队来说完全无感。如果你明确不需要某些后台队列还可以通过sidekiq[queue_selector]之类的参数关掉特定队列但操作复杂度高一些我在5.3节里会再提。3.3 关闭Prometheus/Grafana等监控组件GitLab自带了一套完整的Prometheus监控体系包括Prometheus、Grafana、Node Exporter、Redis Exporter、PostgreSQL Exporter还会启动Alertmanager。这一套东西在庞大集群上是有用的但在小机器上纯属浪费资源而且它们本身就在不停采集数据、写时间序列数据库给CPU和磁盘又加了一层负担。我建议直接把整条监控链全关掉prometheus_monitoring[enable] false grafana[enable] false prometheus[enable] false alertmanager[enable] false node_exporter[enable] false redis_exporter[enable] false postgres_exporter[enable] false如果还有旧版本用的参数gitlab_rails[prometheus_enabled]也可以一并设置为false。全部关闭后GitLab自带的“监控”页面会没数据但这不影响日常使用。真需要监控的话宝塔面板看系统负载和进程就足够了不必让GitLab再养一套监控全家桶。我在一台4G机器上关掉这套组件后内存直接少了将近500MB效果非常直观。3.4 给数据库腾内存PostgreSQL在GitLab里负责存储绝大多数业务数据它的内存参数同样需要调整。GitLab默认的shared_buffers可能跟实际机器内存不匹配。shared_buffers是PostgreSQL的共享缓冲区大小设太大容易挤占系统内存设太小又会导致数据库频繁读盘。对小内存机器我建议这样设置postgresql[shared_buffers] 128MB postgresql[max_worker_processes] 42G内存机器可以压低到128MB4G机器用256MB就差不多了。数据库这块不建议压得太狠否则会影响代码仓库的查询性能。如果机器内存够大可以适当调大到物理内存的25%左右不过这里目标是省内存思路要先摆正。Redis那边默认配置占用的内存不算多一般几十MB可以不专门调。3.5 其他能关就关的功能组件除了上面几个大头GitLab里还有不少可选组件在小团队场景下属于“用不上但耗资源”容器镜像仓库Registry如果不用GitLab自带的Docker镜像仓库可以关闭GitLab Pages静态页面托管服务绝大多数人用不上自带的GitLab Runner默认不会启动但如果误开了也会消耗资源关闭方式registry[enable] false gitlab_pages[enable] false另外我还会顺手关闭GitLab不常用的自动备份提醒等功能这些在gitlab.rb里也有对应开关但影响不大。重点是先把Puma、Sidekiq、监控组件、数据库这几块调到位资源占用就能明显降下来。4. 宝塔Docker安装版的完整操作记录4.1 通过环境变量一次配好很多人用宝塔装GitLab走的是宝塔面板的“Docker管理器”直接部署gitlab/gitlab-ce镜像。这种方式最大的好处是干净、易删除但配置方式和直接安装版略有不同。Docker版GitLab同样在后端生成/etc/gitlab/gitlab.rb只是我们通常不会直接进容器去编辑文件而是通过环境变量GITLAB_OMNIBUS_CONFIG把优化配置传进去。创建容器时docker run命令大致是下面这个样子docker run -d \ --name gitlab \ --restart always \ -p 8080:80 \ -p 8443:443 \ -p 4422:22 \ -v /opt/gitlab/config:/etc/gitlab \ -v /opt/gitlab/logs:/var/log/gitlab \ -v /opt/gitlab/data:/var/opt/gitlab \ -e GITLAB_OMNIBUS_CONFIGprometheus_monitoring[enable]false; grafana[enable]false; sidekiq[max_concurrency]5; puma[worker_processes]2; puma[max_threads]4; postgresql[shared_buffers]128MB \ gitlab/gitlab-ce:latest多个配置项直接用分号隔开写在一条环境变量字符串里。注意PostgreSQL的shared_buffers这个值如果在环境变量里传要用单引号包住数字加单位的字符串避免和shell的分号冲突整体引号也要注意。这种方式的优点是容器启动时就生效省得二次配置。缺点也很明显——后续要改参数你得重新创建容器或者进容器改配置。我第一次就是忽略了这点结果改完环境变量忘了重建容器配置怎么都不生效。4.2 进入容器修改配置的方式如果容器已经跑起来了不想重建也可以直接进入容器内部修改docker exec -it gitlab /bin/bash进入容器后vim /etc/gitlab/gitlab.rb按照第3节里的内容修改然后执行gitlab-ctl reconfigure注意容器内不一定装了vim可能只有vi甚至需要先apt update apt install -y vim才能用vim。我吃过这个亏在容器里输vim提示command not found后来直接用的sed去替换配置。改完配置后还有一个细节如果用的是Docker挂载方式容器内的/etc/gitlab/gitlab.rb映射到宿主机/opt/gitlab/config/gitlab.rb所以你完全可以在宿主机上直接编辑这个文件再重启容器docker restart gitlabGitLab容器重启后会自动应用配置不需要再手动执行reconfigure。这一点和直接安装版不太一样很多人搞混。宿主机直接编辑挂载文件的优势是随时能改、不怕容器的文件系统丢失我在后续维护中基本都采用这个方式。4.3 端口和存储路径的注意事项用宝塔装GitLab时端口冲突是高频问题。宝塔自带的Nginx默认占用80和443端口而GitLab容器内部也封装了自己的Nginx所以宿主机上绝对不能再把80和443直接映射给GitLab容器。常见的做法是用8080映射容器内的80用8443映射容器内的443SSH端口则建议用4422或别的空闲端口映射容器内的22。-p 8080:80 -p 8443:443 -p 4422:22启动之后访问地址是http://服务器IP:8080SSH克隆地址需要设置成ssh://git服务器IP:4422/group/project.git。这个SSH端口还要在gitlab.rb里同步告诉GitLab不然页面上显示的克隆地址会不对gitlab_rails[gitlab_shell_ssh_port] 4422如果是Docker挂载方式这行配置同样写在宿主机对应的/opt/gitlab/config/gitlab.rb里改完重启容器即可。存储路径这里再强调一次很多宝塔用户把数据直接写在系统盘系统盘被GitLab撑爆的情况很常见。挂载三个目录到独立数据盘是更稳妥的选择前面docker run命令里的/opt/gitlab/config、/opt/gitlab/logs、/opt/gitlab/data三个路径建议都放在空间充裕、最好是SSD的数据盘上。5. 优化后的效果与常见问题排查5.1 配置不生效怎么办优化过程中遇到最多的问题就是改了配置但内存一点没降。我在第4节里也提过Docker版最常见的原因是改完环境变量没有重建容器或者改了宿主机挂载的gitlab.rb之后只重启了容器但没有等待GitLab应用配置。更隐蔽的一种情况是reconfigure执行了但GitLab的进程没有完整重启Puma和Sidekiq还保留着旧进程。这时候不要只跑reconfigure干脆把相关服务手动重启一遍gitlab-ctl restart puma gitlab-ctl restart sidekiq gitlab-ctl restart postgresql如果内存还是没变化用ps aux | grep bundle看看进程数量有没有变化。理论上一套配置正确执行完后Puma worker数量、Sidekiq线程数量都会降到设定值。注意reconfigure和restart都需要一定的执行时间等1到2分钟后再观察是正常的。另外一个容易忽略的点GitLab有大量延迟加载机制即使进程数降下来了内存可能也不会瞬间释放。你可以用sync echo 3 /proc/sys/vm/drop_caches来回收系统缓存但这只是把缓存收回不是根治。根治还是看进程数量是否正确、占用是否稳定跑个半天后再看内存趋势才比较准。5.2 功能异常排查页面访问、代码推送、CI任务优化之后功能异常的情况也见过不少。最典型的是页面502。如果你的Puma worker从4个降到了1个而团队访问量并不低可能会出现并发请求处理不过来导致502。解决办法是适当提高worker数量或者调高max_threads小团队一般worker_processes2、max_threads4就能覆盖几十人同时访问。代码推送变慢或卡住优先检查SSH端口和clone地址。很多人在宝塔里映射了4422端口但忘了配置gitlab_shell_ssh_port导致页面显示的还是22端口推代码时客户端连不上。修改配置后最快的方法是直接看页面的clone地址是否正确。CI任务不跑先别怀疑优化方案。GitLab的Runner和Sidekiq是两码事如果你原来有注册RunnerSidekiq并发只影响任务执行速度不影响Runner连接。但如果关了Prometheus等组件CI日志里的监控数据会缺失这属于正常现象不影响流水线执行。5.3 二次优化的补充技巧配置调到上面那一步大部分机器的资源占用已经能降到可接受范围了。如果还想再压一压可以试试下面几个补充手段。第一个是给系统加Swap。对于2G内存的小机器Swap虽然不是万灵药但能防止极端情况下的OOM杀进程。我习惯设置4G的Swap文件fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstab有了Swap之后内存不够时会先走Swap页面慢一点但至少不会整个GitLab挂掉。注意如果是Docker容器运行Swap配置是在宿主机层面生效的。第二个是关闭一些确实用不到的后台队列。GitLab的Sidekiq有多种队列比如邮件推送、仓库统计、导入导出等。如果团队用得少可以在Sidekiq配置里按需关闭。不过这个操作需要你对队列比较熟悉不建议新手上来就动容易把内置功能弄废。我在生产环境里一般只保留默认队列把邮件队列的并发单独压低就够了。第三个是设置定时重启但这算是“下策”。在内存确实不够的情况下可以每天凌晨低峰期执行一次gitlab-ctl restart sidekiq让Sidekiq的进程和内存重置。之所以说它是下策是因为频繁重启本质上是在掩盖配置没调好的问题而且重启期间部分后台任务会中断。建议是把前面几节的内容都做一遍再用定时重启兜底。我在实际维护过程中的体会是GitLab的资源问题没有一劳永逸的魔法开关需要你理解这个产品的运行机制然后根据自己的硬件和团队规模做取舍。2G内存的服务器跑社区版GitLab优化后可以做到内存占用控制在1.2G到1.5GCPU基本平稳日常使用不卡顿。但要跑到和8G机器一样的体验那不现实硬件底子是绕不开的。如果你的团队规模超过几十人或者仓库数量很多、CI任务很频繁建议还是把服务器内存升到8G以上那才是真正稳妥的方案。