香港独服自建GitLab仓库怎么选

团队里的代码从几个人各管一摊，慢慢变成十几个人在同一个项目上互相提交，最初放在哪都不太在意。等到免费额度不够用、克隆越来越慢、评审页面点开要等半天，才发现托管这件事也得认真对待。是自己搭一台机器放代码，还是继续花钱租服务，配到什么程度才不浪费，这些问题没有标准答案，但有几条能算清楚的路。这篇从资源占用、方案取舍、容量估算、备份安排几个角度把这件事拆开讲，提到的香港独服配置档位也能对应到自己团队的规模。

仓库服务器吃哪几样资源

代码托管服务跟普通网站不是一回事。它日常大部分时间几乎不干活，一旦有人推代码、开合并请求、刷新评审页面，就会在几秒内把几个核心跑到满载。衡量一台机器够不够，看的不是平均负载曲线，而是这些尖峰能不能平稳过去，尖峰过去之后会不会留下满屏的等待。

内存是第一道关口。GitLab 整套装下来，主进程、Sidekiq 后台任务、Postgres、Redis 几样常驻加起来，安静状态下就要占掉六到八 GB。给到十六 GB 才算有喘息的地方，三十二 GB 能跑得比较从容。机器只有八 GB 的时候，页面点开会明显停顿，推送稍大的仓库容易超时，这种卡顿很难靠调参数根治。

CPU 的用法很特别。平时占用很低，但合并请求的差异对比、代码高亮、全文搜索这几类操作，会短时间拉满多个核心。核多比主频高更管用，因为这类活儿本身能拆开并行。二十核四十线程这一档，承接十几个人每天几十次推送和评审，基本感知不到排队。

磁盘是最容易被低估的一项。仓库本身不大，可每次合并留下的对象、每个分支的引用、附件和流水线制品都会持续往里堆。固态盘的价值不在容量，而在大量小文件的随机读写能力。几百 GB 的固态作为起点，配上定期清理，跑几十个中小仓库是够的。

网络的要求反而低。推拉代码主要看往返延迟，流量并不大。香港机房到内地的往返通常在几十毫秒，日常提交评审的手感是可以接受的。真正的带宽压力出现在首次克隆大仓库和恢复备份这两个场景，平时完全用不满端口。把这几项拼起来能看到一个规律：仓库服务器属于中等偏内存的类型，不需要顶配处理器，也不需要海量带宽，但内存余量和磁盘随机读写的下限不能省。按这个思路对照配置表，比盯着核数挑要靠谱。

GitLab 和轻量方案差在哪

直接上 GitLab 是省心的选择，功能完整、界面熟悉，新人进组不用额外培训。代价是资源占用高，一次大版本升级要预留维护窗口，升级完还得逐项验证插件和集成没被改坏。这套东西适合已经把它的能力用起来的团队，用不上那些能力的时候，这套东西就是个负担。

轻量方案像 Gitea、Forgejo 这类，单个进程跑起来，内存几百 MB 就够，合并请求、议题、Webhook、权限组这些基础能力都有。几个人的小组、十几个仓库的规模，一台低配机器就能跑得很顺，升级也只是换个二进制文件重启，出问题回滚也快。

差别主要落在未来。GitLab 自带的流水线、容器镜像仓库、代码扫描、依赖分析这些能力，轻量方案要么没有，要么得一个个外挂拼起来。团队如果已经靠这些能力省下了人力，搬家的成本就不只是迁移几百个仓库那么简单，整条协作流程都要重搭，这个成本经常被漏算。

判断方式其实很朴素：把团队真正在用的功能列一遍。只用提交、评审、议题、通知，轻量方案完全够；已经在用流水线、制品库、环境部署，那就按 GitLab 的资源需求去配机器，别指望四 GB 内存跑全套。选方案这一步定错，后面配多大机器都是错的方向，先定方案再谈预算，这一步没人能替你决定，问得越早越省钱。

一台机器能放多少个仓库

这个问题不能按仓库个数直接换算，因为仓库和仓库的体量差得远。一个前端项目几十 MB，一个带历史素材的游戏客户端能到几个 GB。估算的时候先按现有仓库的总占用×未来一年的增长倍数，再留出三成余量给制品和备份临时文件。

接着看并发。真正同时操作的人不会很多，十几人的团队里，同一秒提交或者刷评审页面的通常不超过三五个。仓库服务器对并发的敏感度低于对内存的敏感度，机器卡住多数时候是内存不够触发交换，而不是核心被占满。

大仓库要单独拿出来算。历史很长、二进制文件很多的项目，克隆一次就要走几百 MB，每次全文搜索都会把这些对象重新读一遍。这类仓库最好控制在少数几个，并且定期做历史瘦身，否则它们会拖慢整台机器上所有人的操作。

制品文件是最隐蔽的增长点。流水线跑一次就产出一份打包文件，默认保留周期设得很长的话，几个月就能吃掉几十 GB。把保留策略按分支区分开，主干留久一点，特性分支三天就清，容量曲线会平缓很多。

备份会占用额外空间和额外 IO。做本地全量备份时，磁盘写入会翻倍，这段时间内提交和评审都会变慢。把备份时间放在夜里，并且备份目标放到另一块盘或者另一台机器，能避免和白天的工作抢资源。

人数少但仓库多的团队是另一种情况。人不多，并发不高，可仓库数量上百，每周都有新项目建起来。这种场景对 CPU 的要求很低，反而更在意磁盘容量和小文件读写的稳定性，配置上可以往大容量固态倾斜。

落地的做法是先小步试。装好之后观察两周的内存曲线和磁盘队列，如果常驻内存稳定在总内存的六成以内、磁盘队列很少超过个位数，说明仍有余量可以继续加仓库。等到内存常态压在八成以上、评审页面开始出现秒级以上的等待，就该准备下一步了。

备份和恢复怎么安排

代码仓库的备份比数据库简单，但也有坑。GitLab 自带的备份命令会把数据库、仓库、附件、配置分别打包，执行期间对服务的写入有影响，放在低峰时段跑是前提。备份文件要落到另一块盘或者另一台机器上，和源数据放在一起等于没备，一次误删就两头都没了。备份盘用上个月淘汰下来的旧机器也行，反正只要求能装下、能读出。别把备份和源数据放在同一块物理盘上，盘坏了就是一起没。

只做备份不做恢复演练，等于在赌运气。每隔一段时间挑一份备份，在临时环境里完整还原一次，确认仓库能克隆、合并请求记录还在、权限组没丢。演练过的团队往往第一次就会发现问题，比如附件目录没被包含进来，或者某类外部存储的对象没有同步。还原要计时，别只看到「成功」两个字就收工，数据库导入、仓库重新索引这段往往比打包本身更耗时间，几小时到一天都正常，别把演练排在有发布的日子。

异地那一份不能省。机房级别的故障概率低，但一旦发生，本地备份和源数据一起没掉。按周把全量备份同步到另一台机器或者对象存储上，成本不高，换来的是最坏情况下能重建。备份策略写在文档里，交接时不会因为换了人而中断。保留几份也要定下来，按周保留最近四周、按月留一份季度的，硬盘空间和恢复点之间取个平衡，实在装不下就只留周备份，备份不完整比没有更危险。

什么时候该拆成两台

第一类信号是资源互相挤压。跑流水线的时候，评审页面跟着变慢；做备份的时候，推送开始超时。两件事本来不该互相影响，出现这种牵连，说明一台机器的内存和 IO 已经被分完了，再往里加仓库只会让所有人一起等。

第二类信号是故障面变大。代码托管一旦挂掉，整个团队的提交、评审、发布全部停摆，比单个业务站点宕机的影响还直接。把所有东西压在一台上，一次磁盘故障就要面对数据恢复和业务中断两件事同时发生。

拆的方式有几种，从轻到重排。最轻的是把流水线执行器拆出去，让它单独跑在一台机器上，重活不再抢主机的内存和磁盘；再重一点是把数据库或者 Redis 独立出去；最重的是把代码托管和周边服务彻底分开，各占一台。

拆之前要想清楚网络。数据库拆出去之后，应用和数据库之间的往返延迟会直接影响页面响应，两台机器最好在同一机房、同一内网，跨机房拆分往往得不偿失。

迁移窗口的安排比拆本身更考验人。切换当天要停止写入、做一次全量同步、改配置、验证权限和钩子、再放开访问。整个过程按小时计，提前把回滚方案写清楚，旧机器保留几天不关机，出问题能立刻切回去。

成本账也要算。两台中等配置加起来，往往比一台高配便宜，而且故障隔离带来的可用性提升是实打实的。只有当团队规模很小、仓库数量有限的时候，单机才更划算。

判断的落点可以很具体：内存常态超过八成、备份和流水线明显互相影响、团队对停机时间的容忍度低于一小时，这三条里中了两条，就该考虑拆。

七百五和九百这两档怎么挑

七百五这一档给的是二十核四十线程、六十四 GB 内存、一 TB 固态、两千兆端口。它的定位很清楚：中等团队的主力仓库机，几十个仓库、十几个人日常使用，内存和磁盘都不用太抠着算。端口够大，首次克隆和恢复备份不会等太久。

九百这一档把内存翻到一百二十八 GB、处理器换成单颗二十四核四十八线程，固态反而是八百 GB。它的强项是内存余量和并行能力，适合仓库数量多、同时跑流水线和代码扫描的团队，容量靠定期清理和大仓库瘦身来维持，而不是靠堆盘。

三百九十九这一档十核二十线程、三十二 GB 内存，作为起步或者备用机很合适。轻量方案跑在上面绰绰有余，或者拿它做流水线执行器、做备份中转，把重活从主力机上挪走，整体成本反而更可控。挑的时候按顺序问三个问题：团队多少人、仓库总量多大、有没有在跑流水线。人数决定内存下限，仓库总量和清理策略决定磁盘，流水线决定要不要拆执行器。三问答完，档位基本就定下来了，不用在参数表上来回比较。

实际部署时留一成资源不分配，给系统缓存和突发峰值。固态盘的容量不要顶到满，八成以内写入性能才稳定。端口虽然是两千兆，跨境的实际吞吐会打折，恢复备份这类大流量动作安排在夜里更稳妥。想按自己的规模对照具体机型，可以从云途渠道的香港独服列表看起，也可以直接翻另一条渠道的机型比较价格与配置。