Que hardware um build server precisa?

Quantos núcleos de CPU um servidor de build precisa?

Quantos o seu grafo de build conseguir rodar ao mesmo tempo: as etapas de compilação se distribuem pelos núcleos, enquanto os links finais e os geradores de código costumam rodar em um só. O Ninja roda jobs em paralelo por padrão. Com o Make, o guia do LLVM diz para passar -j com aproximadamente o seu número de CPUs.

A documentação do Android do Google traz os números públicos mais claros. O Google compila o Android em máquinas de 72 núcleos com 64 GB de RAM: uma build completa leva cerca de 40 minutos. Em uma máquina de 6 núcleos com 64 GB, a mesma build completa leva cerca de 6 horas.

Doze vezes mais núcleos reduziram a build completa do Android do Google em cerca de nove vezes, de 6 horas para 40 minutos. Esse é o número do Google, não nosso: Lumenfer não publica benchmarks. O guia do compilador Rust diz a mesma coisa com palavras mais simples. Ele pede 2 núcleos e afirma que 10, 20 ou mais não é demais.

Etapas de thread única ainda definem um piso. Um link final longo roda na velocidade de um núcleo, então a velocidade por núcleo também importa. Nosso guia da melhor CPU para um servidor alugado pesa a frequência de clock contra o número de núcleos. Quantos núcleos você precisa mapeia núcleos para cargas de trabalho.

Quanta RAM um servidor de build precisa?

O suficiente para cada job paralelo no seu pico mais o linker: o Android define um mínimo de 64 GB, e o Chromium recomenda mais de 16 GB. Ficar sem memória não só deixa a build mais lenta. Isso empurra a máquina para o swap ou mata o job.

• O linking é o pico de memória. O guia do LLVM avisa que o linking pode usar muita memória. A opção LLVM_PARALLEL_LINK_JOBS limita links simultâneos com o Ninja; defina como 1 quando a memória estiver curta.
• Símbolos de debug custam RAM e disco. O Chromium sugere is_debug = false ou symbol_level = 0 quando os links falham por falta de memória.
• O swap é uma rede de segurança, não capacidade. O Chromium pede pelo menos 32 GB de swap em SSD em uma máquina de 8 GB, e 16 GB em uma de 16 GB.
• A RAM pode substituir gravações em disco. O Chromium permite um tmpfs para a saída da build, desde que RAM mais swap consigam comportá-la.

Para dimensionar a sua própria build, meça a memória de pico de um job com /usr/bin/time -v e multiplique pelos jobs paralelos que você planeja. Some o maior link por cima.

Que armazenamento um servidor de build precisa?

NVMe local rápido com espaço para fontes, saídas e caches: o Android pede 400 GB livres, o Chromium pede 100 GB. As builds leem milhares de arquivos pequenos e gravam object files em rajadas. O NVMe local mantém isso perto da CPU. Nossa comparação de NVMe e SSD SATA em servidores alugados explica a diferença.

• Builds de debug ocupam muito mais espaço. O guia do LLVM coloca uma build de debug completa do LLVM e do Clang em 15 a 20 GB, contra muito menos para Release.
• Caches precisam do próprio orçamento. O ccache acelera recompilações armazenando resultados anteriores, com limite padrão de 5 GiB. Árvores grandes precisam de um limite maior.
• Caches compartilhados superam discos maiores. O ccache pode consultar armazenamento remoto depois do cache local. A ferramenta de build padrão do Chromium, o Siso, usa execução e cache remotos em vez disso.

Planos com dois discos vêm com o sistema operacional em um espelho RAID 1 por software; peça ao suporte antes da entrega se preferir RAID 0 ou dois discos separados. Em uma máquina de build, o RAID 0 dobra o espaço de rascunho, e um disco morto só perde caches que você pode reconstruir. De qualquer forma, mantenha as fontes no git e os artefatos fora da máquina.

As builds devem rodar no próprio controller de CI?

Não: o Jenkins considera executors no controller uma má prática e diz para delegar jobs aos agents. O guia de hardware dele descreve os agents como máquinas x86 genéricas com memória suficiente para as builds que rodam. O controller fica pequeno. O Jenkins conta cerca de 2 MB ou mais de memória por nó de build conectado.

Com o GitHub Actions, o GitHub é o controller e o seu servidor é o agent. A configuração de um runner self-hosted do GitHub Actions em um servidor alugado percorre registro, serviços e segurança. Se vale a pena em comparação com os minutos hospedados é calculado em runner self-hosted vs custo do GitHub-hosted.

Um servidor de build precisa de memória ECC?

Não para CI do dia a dia, mas prefira para builds de release que você assina e distribui. A memória ECC detecta e corrige erros de bit único antes que cheguem a um arquivo. Sem ela, um bit invertido raro pode acabar dentro de um artefato que passa em todos os testes.

Os planos Lumenfer com ECC são Lumen 6 (32 GB DDR5 ECC), Lumen 24 (256 GB DDR5 ECC) e Lumen 32 (384 GB DDR5 ECC). Os planos Ryzen listam DDR5 padrão. Nossa página sobre se você precisa de RAM ECC cobre o trade-off.

Qual plano Lumenfer combina com qual build?

Combine o plano com a sua maior build e depois adicione um job paralelo por cada 4 a 8 threads livres. Todo plano é uma máquina inteira: sem hypervisor, sem vizinhos. Somente imagens Linux: Debian, Ubuntu, AlmaLinux e Rocky Linux, além do Proxmox VE para rodar máquinas virtuais no hardware. Windows não é oferecido.

Na verificação da Lumenfer sobre 30 October 2026, 12 de 18 hostings cripto sem KYC vendiam o servidor dedicado mais barato em uma CPU lançada antes de 2022. Todo plano Lumenfer roda uma CPU de 2022 ou mais nova com memória DDR5. Preços e termos completos estão na página de preços da Lumenfer.