虚拟机配置GitLab时，内存不足怎么办？
当虚拟机内存不足导致GitLab无法正常运行时，最直接的解决路径是：先优化GitLab自身的资源占用，再考虑合理配置Swap交换空间，最后才是升级虚拟机内存配置。很多人一遇到内存不足就急着扩容，结果花钱不少问题却没解决，GitLab本身是个资源大户，但它的默认配置是为物理服务器设计的，在虚拟机上跑通常有相当大的调优空间，本文从具体操作入手，帮你一步步把内存占用降下来。
为什么虚拟机跑GitLab特别吃内存
先弄清楚问题的根源,GitLab是一个集成度极高的DevOps平台，它不是一个单独的程序，而是由Unicorn/Puma（Web服务器）、Sidekiq（后台任务处理器）、PostgreSQL（数据库）、Redis（缓存）、Prometheus（监控）等十几个组件组成的集群，每个组件都要常驻内存，加起来自然吓人。
业内专家指出,GitLab官方推荐的硬件配置是8GB内存起步，这还不包括操作系统的开销，但多数个人开发者、小型团队用的是2GB或4GB的云服务器，跑起来自然会捉襟见肘，尤其在国内常见的简米云、酷番云轻量应用服务器上，2GB内存跑默认配置的GitLab，开机后内存占用基本就是90%以上，系统随时可能触发OOM Killer把进程杀掉。
还有一个经常被忽视的场景：很多人用的是Windows下跑VMware或VirtualBox虚拟机来装GitLab，这种情况下，虚拟机不仅要用自己的内存，还要承受Windows宿主机和虚拟化软件本身的开销，内存不足的问题会被进一步放大，如果你是在本地虚拟机里测试GitLab，内存问题的严重程度往往比云服务器更突出。
先动手优化GitLab配置，把内存降下来
在考虑花钱升级配置之前,先花几分钟改几个配置文件，效果立竿见影，GitLab的主配置文件在/etc/gitlab/gitlab.rb，改完之后记得执行gitlab-ctl reconfigure让配置生效。
精简组件，关掉用不到的服务
GitLab默认开启了很多组件,其中相当一部分对个人或小型团队来说根本用不到，打开配置文件，找到这几项，按需处理：
- Prometheus监控全家桶：这是内存大户之一，包括Prometheus、Grafana、node-exporter、redis-exporter等一堆监控组件，能占掉500MB-1GB内存，如果不是特别需要监控面板，直接在配置文件里加上
prometheus_monitoring['enable'] = false，reconfigure 即可。 - GitLab Pages：如果你不需要用GitLab托管静态网站，关闭它，在配置中找到
gitlab_pages['enable'] = false取消注释。 - Mattermost：这是GitLab自带的聊天工具，大多数用不到，确认
mattermost['enable'] = false处于生效状态。
调整Puma/Unicorn的Worker数量
这是决定内存占用的核心参数,Puma（新版本）或Unicorn（老版本）是GitLab的Web服务器，它通过开启多个Worker进程来并发处理请求，每个Worker进程要吃掉300-500MB内存，默认配置会根据CPU核数自动计算Worker数量，2核CPU的机器可能就开3-4个Worker，内存自然爆。
手动把Worker数量压下来是最直接的办法,在gitlab.rb中找到对应配置：
puma['worker_processes'] = 2
puma['min_threads'] = 1
puma['max_threads'] = 2如果你用的是老版本GitLab,配置项是unicorn['worker_processes']，同样改成2即可。2个Worker基本能满足5-10人小团队的日常使用，超过这个规模建议直接换机器。
限制Sidekiq的并发数
Sidekiq负责处理GitLab的后台任务,比如发送邮件、执行CI（持续集成）流水线、仓库清理等，它默认的并发数是25，这个小参数能让内存占用飙升到1GB以上，在配置文件中找到sidekiq['concurrency']，把它改成5，CI任务用得多可以改成8，但建议先从5开始试，对于个人开发者，CI使用频率不高，5就已经很宽裕了。
配置Swap交换空间，给内存加个缓冲区
调整完配置之后,如果内存还是紧巴巴的，配置Swap是性价比最高的补救方案，Swap就是拿磁盘空间当内存用，性能虽然远不如物理内存，但能有效防止OOM Killer把GitLab杀掉，行业共识认为，对于2GB内存的虚拟机，配置2GB-4GB的Swap是合理范围。
在Linux虚拟机上手动创建Swap
这里以最常见的CentOS/Ubuntu系统为例，直接按步骤操作：
- 创建Swap文件。
fallocate -l 2G /swapfile，如果提示not supported（不支持），就用dd if=/dev/zero of=/swapfile bs=1M count=2048。 - 设置权限（安全性检查，不设置也行但不能偷懒）：
chmod 600 /swapfile - 格式化为Swap格式：
mkswap /swapfile - 启用Swap：
swapon /swapfile - 验证结果：
free -h，应该能看到Swap一行显示0G。 - 让系统重启后自动挂载,编辑
/etc/fstab文件，在末尾追加一行/swapfile swap swap defaults 0 0。
这里有一个关键参数值得注意：vm.swappiness。 这个值控制系统使用Swap的积极程度，默认是60，意思是内存使用超过40%时就开始用Swap，对于跑GitLab的虚拟机，建议把它调低到10左右，让系统优先使用物理内存，把Swap作为缓冲而不是依赖：
sysctl vm.swappiness=10这条命令只对当前会话生效,要永久生效需要把vm.swappiness=10写入/etc/sysctl.conf。
Swap的另一个作用是缓解内存的突发压力，比如团队五六个人同时推代码，内存峰值会瞬间拉高，有Swap兜底，至少不会直接触发OOM Kill。
在VMware或VirtualBox虚拟机里额外注意
如果你用的是本地虚拟机,除了给虚拟机系统配置Swap之外，还可以考虑给VMware或VirtualBox虚拟机增加内存，具体操作很简单：先关闭虚拟机，然后在VMware的“虚拟机设置”里调整内存滑块，VirtualBox在“设置-系统-主板”里改“内存大小”，建议直接把宿主机空闲内存匀1-2GB给虚拟机，这一步是在虚拟机外部调整，和系统内配置Swap是两回事，二者可以叠加使用。
换个思路：小内存跑GitLab值得吗
如果你的虚拟机内存只有1GB或更低，优化配置和Swap加起来也未必流畅，这时候要理性评估一下，是不是非用GitLab不可，业内比较务实的做法有两种：
- 换用Gitea或Gitee（码云）：Gitea是一个极轻量的Git托管平台，512MB内存就能跑得飞起，操作习惯和GitLab高度相似，个人项目迁移成本极低，在1GB内存的虚拟机上，Gitea是更理性的选择。
- 使用GitLab官方提供的Omnibus Docker镜像（Docker方式部署）：虽然Docker容器本身有一定内存开销，但官方镜像比手动安装的组件更精简，内存占用相对可控，适合有一定运维经验的人。
这引出一个重要问题：GitLab和Gitea的虚拟机内存占用对比，GitLab完整版在2GB内存的机器上，优化后占用约1.2GB-1.5GB；Gitea在512MB内存的机器上占用约200MB-300MB，这不是说GitLab不行，而是它的功能复杂度决定了它的资源需求上限，对于只需要代码托管、Issue跟踪、简单的CI/CD（持续集成/持续部署）的团队，两者体验差异并不大，对于追求极致低配、用最低成本跑起代码托管服务的用户来说，轻量级替代方案在低内存虚拟机上的优势是压倒性的。
排查虚拟机配置GitLab内存不足的步骤清单
遇到问题时按顺序排查,能省不少时间：
- 先看实际情况：执行
free -h查看内存和Swap使用量，用ps aux --sort=-%mem | head -15列出内存占用最高的进程，确认是不是GitLab相关进程在吃内存。 - 确认有没有配置Swap：
swapon --show，没显示说明还没配，优先补上。 - 检查资源配置：去云服务商控制台或虚拟机软件里确认分配给这台机器的内存额度，确认没有超分。
- 确认系统版本和GitLab版本：老版本GitLab（12.x及以下）的Unicorn配置路径和新版本Puma（13.x及以上）不同，别改错位置。
- 执行优化配置并用
gitlab-ctl reconfigure重载，观察24小时内内存走势，判断是否稳定。
常见问题速答
问题：我执行gitlab-ctl reconfigure之后，GitLab直接启动不了了，怎么办？
先检查配置文件格式是否正确,执行gitlab-ctl config验证一下配置内容，如果是语法错误，GitLab会直接报错，改完配置后启动需要一些时间，耐心等2-3分钟再执行gitlab-ctl status看状态，如果一直起不来，用gitlab-ctl tail查看日志定位具体哪一行配置出了问题，多半是Worker数值配成了0或者负数。
问题：我把Worker数量调成1，内存还是快满了，还能怎么压缩？
可以尝试关闭GitLab的Prometheus监控服务和各类Exporter，再检查是否有大量未清理的CI缓存和日志文件，PostgreSQL的shared_buffers参数可以调低到128MB（默认是256MB），Redis也可以开启内存淘汰策略（maxmemory），但这两个操作建议有一定数据库经验的人来改，新手慎动。
问题：2GB内存的酷番云服务器（轻量应用服务器）装GitLab，用Docker部署是不是更省内存？
不一定,Docker容器内的GitLab镜像（尤其standalone镜像）和裸机安装的内存占用差距不大，甚至因为容器多了一层虚拟化，内存开销反而可能略微增加，Docker的主要优势在于部署和升级方便，不省内存，2GB的酷番云轻量服务器，推荐先按本文方法优化裸机安装，如果实在搞不定再考虑Docker。
回到最开始的问题,虚拟机内存不足跑GitLab，本质上是一个资源与需求的匹配问题，先优化现有资源的使用效率，再考虑Swap兜底，最后才是花钱升级硬件，这是成本最低的路径，GitLab自身的灵活性决定了大多数低配虚拟机经过调优都能获得可用的性能表现，关键在于不要用默认配置直接跑，也不要把内存需求想得高于实际。