香港独服跑 CI 构建机够用吗

提交完代码等构建排队，等半小时之后提示内存不足被杀，做过持续集成的人大概都遇到过这种场面。构建机到底要多少核、多少内存，网上说法从两核够用到三十二核起步都有，看多了反而不知道信谁。这篇按构建这件事真实消耗的资源往下拆：并行编译吃核数，链接阶段吃内存，拉依赖和写缓存吃磁盘，然后讲并发怎么定、缓存放哪、构建产物存多久，以及到底要不要单独买一台跑构建。

构建机吃的是哪几种资源

并行编译主要吃核数。现在的构建工具默认按核数开并行任务，四核和二十核在最开始那一分钟的差别非常直观，编译单元越多差距越明显。核数上去之后，单核性能反而没那么关键，这也是为什么高频少核的机型做构建机并不占优势。

内存是第二个坎。编译走到链接阶段内存占用会突然上去，几个大模块同时链接，32GB 很容易被吃满。一旦触发交换，整台机器的速度会一起掉下来，原本十分钟的构建能拖到四十分钟，日志里还看不出明显报错。

磁盘看随机读写。拉依赖的时候要解压成千上万个小文件，写缓存的时候也是小文件反复覆盖，机械盘在这两个动作上的延迟很明显。很多时候构建时间里有相当一部分不是花在编译，而是花在等磁盘把文件准备好。

网络带宽只在拉依赖和推镜像这两个时刻有用，消耗的是瞬时峰值。构建本身的 CPU 计算并不需要带宽，但依赖拉不下来整条流水线就停在那里，所以稳定性比绝对带宽更重要。

这四样里最容易被低估的是内存。不少团队按核数选机器，核数够了内存差一截，构建跑到一半被杀，还以为是代码有问题。八百元档那台二十四核四十八线程配 32GB 内存，做主力的中等项目构建机核数很富余；七百五十元那台二十核四十线程配 64GB，核数少四个但内存宽裕一倍，链接重的大项目反而更稳。两种配置都能从这条渠道入口翻到。

并发任务开几个才不互相拖

并发数不是越多越好。构建任务之间互相抢内存，两个任务各要 20GB，32GB 的机器就只能排队等前一个结束。并发开得比内存撑得住的多，结果往往不是变快而是整体变慢，因为交换一旦频繁，所有任务都在等磁盘。先压测一次单任务峰值内存，再按七成反推并发，比拍脑袋定数字靠谱，压测结果最好记下来贴在文档里，换项目的时候也能翻出来对比。

经验算法是单任务峰值内存乘以并发数，不超过物理内存的七成。剩下三成留给系统本身、页缓存和临时文件，别让交换有机会上场，交换一旦开始，所有任务的耗时会一起放大，本来十五分钟的构建能拖到一小时。

分支多、提交密的团队，建议把并发定在核数的一半左右，内存不够时优先加内存而不是加核。核多了内存不足，等于给厨房添了更多灶却只有一口锅，反而乱，内存瓶颈是硬瓶颈，核数只是把它暴露得更明显，加到足够内存之前调并发都是白忙，机器规格摆在那里，参数改不动物理上限。

队列要有等待时长监控。排队时间连续几天超过十分钟，说明资源真不够了，或者该把流水线拆开，让打包和测试分别落到不同队列，别让短任务排在长任务后面干等，短任务优先能让反馈更快，团队感受差别很大，改一行代码等二十分钟和等三分钟完全是两种体验。

缓存和依赖仓库怎么放

依赖缓存是构建提速里收益最高的一项。每次构建都从公网重新拉一遍，速度慢还不稳定，网络抖一下整条流水线就失败，重试几次一天的时间就没了。

本地缓存直接放在构建机上最省事，问题是多台构建机之间不共享，各自拉一遍等于浪费。机器多了之后要有一台内网缓存服务器做统一出口，所有构建机都指向它。

容器镜像也是同样的道理。自建镜像仓库放在同机房，拉取速度取决于内网带宽和磁盘，跟公网线路关系不大，这一点经常被忽略，结果把提速的希望寄托在公网带宽上。

缓存必须能失效。依赖版本更新之后旧缓存不光不提速还会拖后腿，得靠版本号或者内容哈希做键，别用固定目录名，固定目录名的缓存迟早会变成事故来源。

缓存目录的磁盘占用要单独监控。一个项目攒半年能到几十 G，多个项目叠加很快把盘写满，写满之后构建失败，报错还往往很隐晦，很难第一时间联想到磁盘。

给缓存目录设上限最实际，超过阈值自动清理最旧的，宁可丢掉一些命中率也别让盘被写满。清理策略要写在流水线里而不是靠人记得。

大容量机型适合做缓存和镜像仓库的宿主。六 TB 机械盘那种配置放在这个位置比放构建机更合适，构建机本身一块固态就够跑，存储交给专门的机器，分工清楚之后扩容也简单，哪一块先满就扩哪一块。

构建产物存哪儿

产物别都存在构建机上。构建机是消耗品，重装一次全丢，事后想找一个两周前的包根本找不回来，上线出问题要回滚的时候会非常被动，找不回来只能重新构建一次，时间全耗在重跑上，事故处理窗口本来就短，经不起再等一轮构建，平时就把产物落地这一环做扎实，省下的是紧急时刻的时间。

常见做法是传到对象存储或者独立的文件服务器，按构建编号建目录，保留最近若干次。目录结构要能一眼看出是哪次提交、哪个分支生成的，命名规则统一之后别人接手也能读懂，别用时间戳加随机串那种只有脚本认识的名字，人一眼看不懂的命名迟早要重新整理一遍，一开始定好规则最省事，后面改动成本高得多。目录里建议同时留一份提交信息和构建时间的小文本，几十个字节，排查的时候很省事。

保留策略按业务定。要发布的产物留久一点，临时测试包留几天就够，长期不清理几百 G 很快就堆起来，清理动作也最好做成自动的，靠人记得删迟早会忘，等盘满了再清就来不及了，存储费用也是成本，堆着不用的旧包每个月都在产生账单，按项目分别设阈值比统一按时间清更合理，核心项目的包留久一点，试验性的项目留几天，删掉的包也要能查得到记录，避免以后说不清哪次上线用的是哪个版本，审计的时候这条记录很关键。

构建机要不要和业务服务器分开

分开的理由里最硬的一条是资源抢占。构建高峰会把 CPU 和内存吃满，同一台机器上的业务跟着卡，用户投诉的时候才发现问题出在构建上，这种排查很费时间，往往查了半天应用代码，才发现是构建脚本在后台跑满了核。

第二条是安全边界。构建机要能从公网拉依赖、能跑各种脚本，暴露面比业务服务器大得多，一旦被利用，放在同一台机器上的业务数据也跟着受影响，隔离本来就是降低爆炸半径，一台机器出事不该牵连整条业务线。

第三条是稳定性要求不同。业务要求七乘二十四小时可用，构建机可以随时重启、随时重装，两种机器混在一起，维护窗口都不好安排，重启一次要协调两拨人，节奏错开就需要额外沟通成本。

预算紧的时候可以合在一起用，但一定要给构建进程设资源上限，用容器或者 cgroup 把 CPU 和内存限住，别让一个构建把整台机器拖死，限制上限之后构建会变慢一点，但业务不受影响。

合在一起的时候构建别跑在业务高峰。定时任务挪到凌晨，或者让构建排队等低峰期再开始，把两者的时间错开能省下不少钱，代价是要接受构建慢一点，这个取舍小团队普遍能接受，先跑起来再优化比一开始就追求完美更实际。

预算允许就直接分开。一台专门跑构建，一台跑业务，互不影响，排查问题也简单，这条入口里各个档位放在一起对比，选型快很多，也更不容易被销售话术带偏。

一个月的构建量怎么估

先数每天的构建次数。按提交频率估，活跃项目一天十几次到几十次都正常，加上定时任务和合并请求触发的构建，实际次数往往比自己估的多，开着自动构建之后一天几十次很常见，合并请求每推一次就跑一轮，累计起来比预想的多一倍。

再算单次构建时长。中等项目五到十五分钟，大型项目半小时以上，把测试和打包都算进去时长还要往上走，测试跑全量和只跑改动的部分差好几倍，增量构建做得好能省一半时间，缓存配到位之后这个差距还会更大。

两个数相乘得到每天的总机时，乘三十就是月度消耗。这个数字直接决定要一台还是两台，也决定了并发能开多大，一台机器月度能提供的机时有上限，超过就只能排队，或者干脆加一台机器分担，按天数粗算不如按总机时算准。

峰值比均值更重要。临近发版的那几天构建量会翻倍，按均值配机器到了关键时刻就排队，团队抱怨的不是机器慢而是等不起，发版当天排队半小时比平时慢一分钟更要命，按峰值准备资源是一种保险，代价是平时会有一点闲置。

算完对照机型：月度总机时在一百小时以内，一台中等配置足够；超过三百小时，就该考虑两台并行或者直接加核，别指望靠调并发把时间挤出来，资源不够的时候调参只是把排队挪了个位置，表面上快了实际总时长没变，该加机器就加。