Capacité du pool et modèle de concurrence
Traitez chaque Mac distant du pool de ressources de build comme un domaine IO unique : un SSD rapide alimente souvent workspaces, caches globaux et parfois les couches Docker. Le CPU peut sembler au repos alors que le disque est saturé — plafonnez donc la concurrence d'après la latence observée des pulls, et non le nombre de cœurs.
Modèle de base : séparez les jobs liés au réseau (clone/fetch Git, téléchargements registry) du travail riche en métadonnées (npm install avec arbre énorme, résolveur CocoaPods, mises à jour Homebrew). Les premiers peuvent se chevaucher modérément ; les seconds doivent rester peu nombreux sur le même volume.
| Scénario | Max ops Git réseau / hôte | Max installs npm / CocoaPods lourdes | Notes |
|---|---|---|---|
| Runner partagé unique (un disque workspace) | 2–3 | 1 | Départ prudent ; n'augmentez que si iowait reste bas et le temps de pull p95 est stable. |
| Hôte de pool (NVMe, volume cache dédié) | 4 | 2 | Séparer /Volumes/cache des workspaces pour limiter la fragmentation. |
| Pic / jour de release | Identique au régime courant | Identique ou inférieur | Préférer la mise en file des jobs à l'augmentation des installs parallèles ; les pics corrèlent corruption de cache et timeouts. |
Étapes (nouveau pool) : (1) Régler l'orchestrateur sur la ligne « runner partagé unique ». (2) Lancer un soak 30 min avec pipelines représentatifs. (3) Si latence disque p95 et taux d'échec des pulls sont stables, augmenter la concurrence Git d'un cran et remesurer.
Files d'attente et verrous pour pulls Git / npm
Les limites de concurrence seules ne résolvent pas la contention en écriture : plusieurs jobs mettant à jour le même préfixe Homebrew, le cache npm global ou le cache CocoaPods peuvent se sérialiser en interne et produire des blocages ou erreurs de verrou aléatoires.
Modèles recommandés :
- Mutex hôte pour gestionnaires mutants : verrou fichier (ex.
/var/run/macpool-brew.lock) autour debrew upgradeou des taps dans des images partagées ; les jobs qui ne lisent que des bouteilles peuvent éviter le verrou. - Cache npm par job :
npm_config_cache=$WORKSPACE/.npm-cachepour l'écriture ; promotion vers un cache partagé en lecture via un job pré-pull planifié. - Git : isolation
GIT_OBJECT_DIRECTORYseulement si vous maîtrisez la réutilisation des packs ; sinon shallow clone et dépôts miroir de référence sur disque.
| Mécanisme | Profondeur de file typique | Timeout d'attente (échec job) |
|---|---|---|
| Mutex global Homebrew | 1 détenteur | 15–30 min (réseau faible) |
| Cache npm partagé (écriture) | 1–2 | 20–45 min |
| Git fetch vers miroir local | 4–8 | 10–20 min connexion + transfert |
Seuils disque et partitionnement des caches
L'APFS gère mal l'espace libre très bas pour les gros écrits séquentiels (packs Git, couches Docker). Appliquez des paliers sur le volume workspace + cache, pas seulement sur la racine système.
| % utilisé (df) | Action automatisation | Action opérateur |
|---|---|---|
| ≤ 80 % | Planification normale | Aucune |
| 80–85 % | Alerte ; réduire pulls concurrents de 1 ; éviction LRU cache | Auditer gros dossiers (DerivedData, Docker, anciens workspaces) |
| 85–90 % | Suspendre nouveaux clones / grosses installs ; finir jobs en cours | Éviction ou déplacement caches ; extension volume ou nœud supplémentaire |
| > 90 % | Arrêt dur des nouveaux jobs ; vidage de file | Nettoyage d'urgence ; vérifier snapshots |
Conservez au moins 15–25 Go libres en garde absolue sur le volume de données principal (le premier seuil atteint l'emporte). Alignez la disposition des caches avec notre article stratégie de cache Git et npm sur Mac distant CI pour des politiques d'éviction prévisibles.
Réseau faible : timeouts, retry et reprise
L'instabilité du pool vient souvent d'orages de retry : après une micro-panne registry, tous les jobs réessayent à la fois. Limitez l'agressivité des retry et privilégiez un backoff exponentiel avec jitter au niveau orchestrateur ou script enveloppe.
| Couche | Paramètre | Valeur de départ |
|---|---|---|
| Git (HTTP) | http.lowSpeedLimit / http.lowSpeedTime |
1000 o/s · 60–120 s |
| Git (wrapper) | timeout kill processus | 45–90 min clone complet ; 15–25 min fetch |
| npm | fetch-timeout / fetch-retries |
300000 ms / 5 |
| curl / générique | --connect-timeout |
30–60 s |
| Retry orchestrateur | plafond backoff | 30 s → 60 s → 120 s (+ jitter) ; max 3–5 tentatives |
Associez les timeouts à des flux reprises : partial clone (--filter=blob:none) si autorisé, réutilisation cache npm, pull Docker avec cache de couches. Pour les réglages Git/Homebrew/npm détaillés, voir la FAQ stabilité des pulls.
WAN faible, miroir interne proche : orienter le pool vers le miroir d'abord ; ne garder des timeouts upstream élevés que sur le dernier saut.
Proxy d'entreprise intermittent : baisser la concurrence Git d'un ; connect timeout 60 s ; rafraîchissement auth proxy en single-flight.
Critères d'acceptation et métriques de supervision
Ne validez un changement de seuils qu'après une semaine ouvrée stable :
- Taux d'échec des pulls < 0,5 % des jobs (réseau + disque).
- Temps p95 de l'étape « fetch dépendances » à ±20 % de la baseline après changement de concurrence.
- Utilisation disque : moins de 5 % du temps au-dessus de 85 % aux heures de pointe.
- iowait (ou proxy latence disque macOS) sans dérive haussière semaine après semaine.
Routez les alertes vers le même canal que redémarrages hyperviseur ou hôte pour corréler pics IO disque et changements de planification.
Questions fréquentes (FAQ)
Un seul gros SSD ou volumes séparés ? Séparer workspace et cache simplifie l'éviction et réduit le risque qu'un job remplisse le disque qui héberge aussi l'OS. Sur un seul volume, resserrez les paliers.
Pourquoi les jobs échouent ensemble après une courte coupure ? Effet de troupeau sur les retry. Ajoutez du backoff avec jitter et baissez temporairement les plafonds de pull concurrent jusqu'à normalisation des erreurs.
Le NFS convient-il aux workspaces Git ? Avec prudence — la latence pénalise Git et les gestionnaires de paquets. Préférez NVMe local pour les workspaces ; NFS pour artefacts majoritairement en lecture si besoin.
Où obtenir de l'aide pour le dimensionnement ? Le centre d'aide MacPull est consultable sans connexion ; pour nœuds dédiés et régions, voir les tarifs et la page achat.
En résumé
Un pool de builds sur Mac distant sain repose sur une concurrence disque d'abord, des files et verrous explicites autour des magasins partagés, des paliers disque en escalier et un comportement timeout / retry conservateur sur réseaux faibles. Partez des tableaux ci-dessus, mesurez pulls et IO une semaine, puis ne modifiez qu'une variable à la fois.
Pour une capacité Apple Silicon prévisible — SSH/VNC, sortie réseau stable et marge pour isoler les caches — les forfaits MacPull de Mac distant permettent de faire grandir le pool sans acheter le matériel. Parcourez le centre d'aide, comparez les tarifs ou passez par la page achat ; poursuivez aussi avec l'accélération des pulls et l'ensemble du blog — le tout sans connexion.
Mac dédié pour votre pool de builds
Nœuds type Mac mini, SSH/VNC — ajustez concurrence et disque sur du matériel maîtrisé. Tarifs, achat et guides sans login.