De quel matériel un serveur de build a-t-il besoin ?

De combien de cœurs CPU un serveur de build a-t-il besoin ?

Autant que votre graphe de build peut en exécuter en parallèle : les étapes de compilation se répartissent sur les cœurs, tandis que les liens finaux et les générateurs de code tournent souvent sur un seul. Ninja exécute les tâches en parallèle par défaut. Avec Make, le guide de LLVM vous indique de passer -j avec à peu près votre nombre de CPU.

La documentation Android de Google donne les chiffres publics les plus clairs. Google compile Android sur des machines à 72 cœurs et 64 Go de RAM : une build complète prend environ 40 minutes. Sur une machine à 6 cœurs et 64 Go, la même build complète prend environ 6 heures.

Douze fois plus de cœurs ont réduit la build Android complète de Google environ neuf fois, de 6 heures à 40 minutes. C'est le chiffre de Google, pas le nôtre : Lumenfer ne publie aucun benchmark. Le guide du compilateur Rust dit la même chose plus simplement. Il demande 2 cœurs et précise que 10, 20 ou plus n'est pas de trop.

Les étapes mono-thread imposent quand même un plancher. Un long lien final tourne à la vitesse d'un seul cœur, donc la vitesse par cœur compte aussi. Notre guide du meilleur CPU pour un serveur loué pèse la fréquence face au nombre de cœurs. De combien de cœurs avez-vous besoin associe les cœurs aux charges de travail.

De combien de RAM un serveur de build a-t-il besoin ?

Assez pour chaque tâche parallèle à son pic, plus l'éditeur de liens : Android fixe un minimum de 64 Go, et Chromium recommande plus de 16 Go. Manquer de mémoire ne ralentit pas seulement une build. Cela pousse la machine dans le swap ou tue la tâche.

• L'édition de liens est le pic de mémoire. Le guide de LLVM prévient que l'édition de liens peut consommer beaucoup de mémoire. Son option LLVM_PARALLEL_LINK_JOBS limite les liens simultanés avec Ninja ; mettez-la à 1 quand la mémoire manque.
• Les symboles de debug coûtent de la RAM et du disque. Chromium suggère is_debug = false ou symbol_level = 0 quand les liens échouent par manque de mémoire.
• Le swap est un filet de sécurité, pas de la capacité. Chromium demande au moins 32 Go de swap SSD sur une machine de 8 Go, et 16 Go sur une de 16 Go.
• La RAM peut remplacer les écritures disque. Chromium autorise un tmpfs pour la sortie de build, tant que la RAM plus le swap peuvent le contenir.

Pour dimensionner votre propre build, mesurez le pic mémoire d'une tâche avec /usr/bin/time -v et multipliez par les tâches parallèles prévues. Ajoutez le plus gros lien par-dessus.

De quel stockage un serveur de build a-t-il besoin ?

Du NVMe local rapide avec de la place pour les sources, les sorties et les caches : Android demande 400 Go libres, Chromium 100 Go. Les builds lisent des milliers de petits fichiers et écrivent des fichiers objets par rafales. Le NVMe local garde cela près du CPU. Notre comparaison du NVMe et du SATA SSD sur serveurs loués explique la différence.

• Les builds debug prennent bien plus de place. Le guide de LLVM situe une build debug complète de LLVM et Clang à 15 à 20 Go, contre bien moins en Release.
• Les caches ont leur propre budget. ccache accélère les recompilations en stockant les résultats précédents, avec une limite par défaut de 5 GiB. Les grosses arborescences demandent une limite plus élevée.
• Les caches partagés valent mieux que de plus gros disques. ccache peut interroger un stockage distant après son cache local. L'outil de build par défaut de Chromium, Siso, prend plutôt en charge l'exécution et le cache distants.

Les offres à deux disques sont livrées avec le système d'exploitation sur un miroir RAID 1 logiciel ; demandez au support avant la livraison si vous préférez un RAID 0 ou deux disques séparés. Sur une machine de build, le RAID 0 double l'espace de travail, et un disque mort ne fait perdre que des caches que vous pouvez reconstruire. Gardez les sources dans git et les artefacts hors de la machine dans tous les cas.

Les builds doivent-ils tourner sur le contrôleur CI lui-même ?

Non : Jenkins qualifie de mauvaise pratique l'exécution des tâches sur le contrôleur et vous demande de déléguer les tâches aux agents. Son guide matériel décrit les agents comme des machines x86 génériques avec assez de mémoire pour les builds qu'elles exécutent. Le contrôleur reste petit. Jenkins compte environ 2 Mo ou plus de mémoire par nœud de build connecté.

Avec GitHub Actions, GitHub est le contrôleur et votre serveur est l'agent. La configuration d'un runner GitHub Actions self-hosted sur un serveur loué détaille l'enregistrement, les services et la sécurité. Savoir si c'est rentable face aux minutes hébergées est calculé dans runner self-hosted vs coût GitHub-hosted.

Un serveur de build a-t-il besoin de mémoire ECC ?

Pas pour la CI de tous les jours, mais préférez-la pour les builds de version que vous signez et livrez. La mémoire ECC détecte et corrige les erreurs sur un bit avant qu'elles n'atteignent un fichier. Sans elle, un bit retourné rare peut finir dans un artefact qui passe tous les tests.

Les offres Lumenfer avec ECC sont Lumen 6 (32 GB DDR5 ECC), Lumen 24 (256 GB DDR5 ECC) et Lumen 32 (384 GB DDR5 ECC). Les offres Ryzen listent de la DDR5 standard. Notre page sur le besoin de RAM ECC couvre le compromis.

Quelle offre Lumenfer convient à quelle build ?

Adaptez l'offre à votre plus grosse build, puis ajoutez une tâche parallèle par tranche de 4 à 8 threads libres. Chaque offre est une machine entière : pas d'hyperviseur, pas de voisins. Images Linux uniquement : Debian, Ubuntu, AlmaLinux et Rocky Linux, plus Proxmox VE pour faire tourner des machines virtuelles sur le matériel. Windows n'est pas proposé.

Dans la vérification de 30 October 2026 par Lumenfer, 12 hôtes crypto sans KYC sur 18 vendaient leur serveur dédié le moins cher sur un CPU lancé avant 2022. Chaque offre Lumenfer fait tourner un CPU de 2022 ou plus récent avec de la mémoire DDR5. Les prix et conditions complets sont sur la page de tarifs Lumenfer.