Ressourcenpool-Kapazität und Parallelitätsmodell
Jeden Remote Mac im Build-Ressourcenpool als eine IO-Domäne behandeln: Eine schnelle SSD trägt oft Workspaces, globale Caches und Docker-Layer. Die CPU kann frei wirken, während die Platte satt ist – begrenzen Sie die Parallelität daher nach gemessener Pull-Latenz, nicht nach Kernzahl.
Basislinie: netzwerkgebundene Fetches (Git clone/fetch, Registry-Downloads) von metadatenlastiger Arbeit trennen (npm mit riesigen Abhängigkeitsbäumen, CocoaPods-Resolver, Homebrew-Formel-Updates). Erstere dürfen sich mäßig überlappen; letztere sollten auf demselben Volume selten parallel laufen.
| Szenario | Max. parallele Git-Netz-Ops / Host | Max. schwere npm / CocoaPods-Installs | Hinweis |
|---|---|---|---|
| Ein gemeinsamer Runner (ein Workspace-Datenträger) | 2–3 | 1 | Sicherer Startwert; nur erhöhen, wenn iowait niedrig bleibt und p95-Pull-Zeit stabil ist. |
| Pool-Host (NVMe, dediziertes Cache-Volume) | 4 | 2 | /Volumes/cache von Job-Workspaces trennen, um Fragmentierung zu reduzieren. |
| Spitzenlast / Release-Tag | wie Normalbetrieb | gleich oder niedriger | Jobs lieber einreihen als parallele Installs erhöhen; Spitzen korrelieren mit Cache-Korruption und Timeouts. |
Schritte (Greenfield-Pool): (1) Orchestrator: max. parallele Jobs pro Host wie Zeile „ein gemeinsamer Runner“. (2) 30-Minuten-Soak mit repräsentativen Pipelines. (3) Wenn p95-Plattenlatenz und Pull-Fehlerrate stabil bleiben, Git-Parallelität um eine Stufe erhöhen und erneut messen.
Git-/npm-Pull-Warteschlangen und Sperren
Parallelitäts-Limits allein beheben keine Schreibkonkurrenz: Mehrere Jobs, die dasselbe Homebrew-Präfix, den globalen npm- oder CocoaPods-Cache aktualisieren, serialisieren intern und erzeugen zufällige Hänger oder Lock-Fehler.
Empfohlene Muster:
- Host-Mutex für mutierende Paketmanager: Dateisperre (z. B.
/var/run/macpull-brew.lock) umbrew upgradeoder Tap-Updates in geteilten Images; reine Lese-Jobs können die Sperre umgehen. - npm-Cache pro Job:
npm_config_cache=$WORKSPACE/.npm-cachefür Schreibzugriff; Promotion in gemeinsamen Read-Only-Cache per geplanter Pre-Pull-Stufe. - Git:
GIT_OBJECT_DIRECTORY-Isolation nur mit Verständnis für Pack-Wiederverwendung; sonst shallow clone und Referenz-Repos auf der Platte.
| Mechanismus | Typische Warteschlangen-Tiefe | Warte-Timeout (Job abbrechen) |
|---|---|---|
| Homebrew globaler Mutex | 1 Inhaber | 15–30 Min. (schwaches Netz) |
| Gemeinsamer npm-Schreib-Cache | 1–2 | 20–45 Min. |
| Git fetch zum lokalen Mirror | 4–8 | 10–20 Min. Connect + Transfer |
Festplatten- und Cache-Partitionsschwellen
APFS verträgt wenig freien Speicher bei großen sequenziellen Schreibvorgängen (Pack-Dateien, Docker-Layer) schlecht. Nutzen Sie gestufte Schwellen auf dem Volume für Workspace + Cache, nicht nur auf dem Root-Dateisystem.
Belegung % (df) |
Automatisierung | Operator |
|---|---|---|
| ≤ 80% | Normale Planung | Keine Aktion |
| 80–85% | Alarm; parallele Pulls −1; LRU-Cache-Eviction | Größte Verzeichnisse prüfen (DerivedData, Docker, alte Workspaces) |
| 85–90% | Neue Klone / große Installs pausieren; laufende Jobs zu Ende führen | Caches auslagieren oder vergrößern; Knoten ergänzen |
| > 90% | Harter Stopp neuer Jobs; Warteschlange leeren | Notfall-Cleanup; Snapshots prüfen |
Zusätzlich mindestens 15–25 GB absolut frei auf dem Hauptdatenträger (was zuerst greift, gewinnt). Cache-Layout an unseren Cache-Strategie-Artikel für Git und npm auf Remote-Mac-CI ausrichten, damit Eviction vorhersagbar bleibt.
Schwaches Netz: Timeouts, Retries und Wiederaufnahme
Pool-weite Instabilität entsteht oft durch Timeout-Retry-Stürme nach Registry-Aussetzern. Aggressivität der Retries begrenzen und exponentielles Backoff mit Jitter auf Orchestrator- oder Wrapper-Ebene setzen.
| Schicht | Parameter | Startwert |
|---|---|---|
| Git (HTTP) | http.lowSpeedLimit / http.lowSpeedTime |
1000 B/s · 60–120 s |
| Git (Wrapper) | Prozess-Kill-Timeout | 45–90 Min. voller Klon; 15–25 Min. fetch |
| npm | fetch-timeout / fetch-retries |
300000 ms / 5 |
| curl / allgemein | --connect-timeout |
30–60 s |
| Orchestrator-Retry | Backoff-Kappe | 30 s → 60 s → 120 s (+ Jitter); max. 3–5 Versuche |
Timeouts mit fortsetzbaren Abläufen kombinieren: partial clone (--filter=blob:none) wo erlaubt, npm-Cache-Wiederverwendung, Docker-Pull mit Layer-Cache. Konkrete Git/Homebrew/npm-Knöpfe im Pull-Stabilitäts-FAQ.
Abnahme und Monitoring-Kennzahlen
Schwellenänderungen erst freigeben, wenn eine volle Arbeitswoche stabil bleibt:
- Pull-Fehlerrate < 0,5 % der Jobs (Netz + Platte).
- p95 Zeit in Stufe „Abhängigkeiten holen“ innerhalb von 20 % der Baseline nach Parallelitätsänderung.
- Plattenauslastung < 5 % der Minuten über 85 % in der Spitze.
- iowait bzw. macOS-Plattenlatenz-Proxy steigt wochenweise nicht an.
Alarme in denselben Kanal wie Host-Neustarts legen, damit On-Call Festplatten-IO-Spitzen mit Scheduling-Änderungen korrelieren kann. Allgemeine Fragen zu Kapazität und Bestellung: Hilfe-Center (ohne Login lesbar).
Häufige Fragen (FAQ)
Eine große SSD oder getrennte Volumes? Workspace und Cache zu trennen vereinfacht Eviction und verringert das Risiko, dass ein Job die Platte mit dem OS füllt. Auf einem Volume strengere Schwellen durchsetzen.
Warum fallen Jobs nach kurzer Störung gemeinsam aus? Thundering-Herd beim Retry. Jitter-Backoff und temporär niedrigere parallele Pull-Caps, bis die Fehlerrate normalisiert.
Ist NFS für Git-Workspaces geeignet? Nur mit Vorsicht – Latenz tötet Git und Paketmanager. Workspaces auf lokaler NVMe; NFS höchstens für lese-lastige Artefakte.
Unterstützung bei Kapazitätsplanung? MacPull Hilfe, Preise und Jetzt kaufen – alles ohne Anmeldung aufrufbar.
Zusammenfassung
Ein gesunder Remote-Mac-Build-Ressourcenpool lebt von platten-first-Parallelität, expliziten Warteschlangen und Sperren um gemeinsame Paketspeicher, gestuften Platten-Schwellen und konservativen Timeout-Retries bei schwachem Netz. Mit den Tabellen in diesem Artikel starten, Pull- und IO-Kennzahlen eine Woche messen, dann nur eine Variable pro Iteration anpassen.
Wenn Sie planbare Apple-Silicon-Kapazität brauchen – SSH/VNC, stabiler Egress und Raum für isolierte Caches – ermöglichen MacPull-Remote-Mac-Pakete Skalierung ohne eigene Hardware. Hilfe lesen, Preise vergleichen oder direkt kaufen; ergänzend Pull-Beschleunigung und den gesamten Blog – ohne Login.
Dedizierter Remote-Mac für Ihren Build-Pool
Mac-Mini-Klasse mit SSH/VNC – Parallelität und Plattenlayout auf Hardware, die Sie steuern. Preise, Bestellung und Anleitungen ohne Login.