2026 Remote-Mac-Speicher voll in sechs Regionen? 1TB/2TB-Erweiterung vs Cache-Governance vs zweite Maschine—FinOps-Dreier-Matrix

Ca. 11 Min. Lesezeit · MACCOME

Fazit: Wenn Ihr dedizierter Remote-Mac (M4 / M4 Pro) in Singapur, Japan, Korea, Hongkong, US East oder US West wiederholt „Datenträger fast voll, Builds langsamer“ meldet, liefert dieser Artikel eine unterschriftsfähige Entscheidung. Wählen Sie zwischen 1TB/2TB-Erweiterung, Cache-Governance und zweiter Peak-Maschine per Dreier-Matrix + 6-Schritte-Runbook + drei Schwellenwerte und koppeln Sie die Wahl an Tages-, Monats- oder Quartals-Leases. Region-Latenz und vollständige POC-Abläufe werden nicht wiederholt; stattdessen folgt auf die Stabilitätsabnahme vor Produktion die typische Folgefrage: Geld in Datenträger investieren oder Nutzung ändern?

Sechs Fehlinterpretationen bei vollem Remote-Mac-Datenträger

  1. Freigebbarer Ballast als strukturellen Mangel behandeln. DerivedData, alte Simulator-Runtimes, Docker-Layer und Gradle-Caches machen oft 40–70 % des rückgewinnbaren Speichers aus. Erst wenn wöchentliche Bereinigung den freien Speicher innerhalb von sieben Tagen wieder unter 15 % drückt, gehört Erweiterung oder zweite Maschine auf die Tagesordnung.
  2. Nur df-Prozente ohne Verzeichnisattribution. APFS-Snapshots, lokale Time-Machine-Snapshots und „Andere Benutzer“ färben die Root-Partition rot; Xcode bremst häufiger an einem linear wachsenden Einzelverzeichnis. Schichtweises du-Sampling statt blindem rm -rf.
  3. Mehr Datenträger als Allheilmittel bei gesättigten CPU-/Speicher-Warteschlangen. Zeigt iostat langfristig <40 % Datenträger-Auslastung bei langsamen Builds, limitiert Parallelität oder Linker-Speicher. Dann schlägt M4 Pro oder eine zweite Maschine 2TB.
  4. Monorepo plus mehrere Simulatoren auf 256GB-Baseline. Partial Clone reduziert Fetch-Volumen, aber lokale Zwischenprodukte und Simulator-Images wachsen pro Branch und OS-Version. Lesen Sie die Monorepo-Slim-Down-Checkliste mit.
  5. Ein Knoten trägt alles in sechs Regionen. Build, UI-Test und Signatur-Upload auf einer Platte füllen Spitzenwochen gleichzeitig. Das Multi-Maschinen-Build-Pool-FinOps-Runbook regelt Rollen; hier entscheiden Sie zuerst die Einzelknoten-Datenträgerstrategie.
  6. Monats-Erweiterung für Zwei-Wochen-Sprint, tägliches Löschen für Jahres-Baseline. FinOps: vorhersehbares Dauerwachstum → 1TB/2TB mit Monats-/Quartals-Lease; kurze Spitzen → Bereinigung plus Tages-Lease für zweite Maschine. Nicht für 14 Tage ein Jahres-Tier fixieren.

Dedizierte Remote-Macs bieten eine klare physische Datenträgergrenze, aber Grenze ≠ automatische Kapazitätsanpassung. Unter Apple-Silicon-Unified-Memory treten Datenträger- und RAM-Druck oft phasengleich auf: parallele Simulatoren, Swift-Inkremental-Builds und Container-Layer-Caches erhöhen IO und RAM gemeinsam. Ohne Dreier-Entscheidung pendeln Teams zwischen „nochmal aufräumen“ und „noch eine Box“—Lease-Budget und Release-Takt leiden.

Der Multi-Region-Kostenleitfaden beantwortet Land und Lease-Länge; dieser Text die Erstbehandlung von Datenträger-Engpässen auf dem gewählten Knoten. Ergänzt die CocoaPods/SPM-Mirror- und Datenträger-Checkliste—Dependency-Tuning reduziert Scheinvollständigkeit, ersetzt aber keine DerivedData-/Simulator-Governance.

Signal Bevorzugt: Cache-Governance Bevorzugt: 1TB/2TB Bevorzugt: 2. Maschine / Pro
Frei <15 % sieben Tage nach Cleanup Nur wenn du >30 % rückgewinnbar zeigt und Standard-Cleanup fehlt Default: strukturelles Wachstum (Multi-Branch-DerivedData) CPU-Warteschlange p95 gleichzeitig gesättigt
Einzelrepo <8GB, 3+ Simulator-OS Ungenutzte Runtimes und Device-Sets entfernen 2+ große OS-Images dauerhaft Parallele UI-Test-Worker >2
Monorepo + affected, wöchentlich voll Blobless- und Cache-Pfade prüfen Default: Zwischenverzeichnisse nicht isoliert Build und Test müssen Datenträger/Maschine teilen
Release-Spitze nur 10–14 Tage Default: Cleanup + Snapshot-Export Quartals-Lease für zwei Wochen nicht empfohlen Tages-/Wochen-Lease für 2. Maschine günstiger
Nach 2TB iowait <8 %, weiter langsam Datenträger nicht primär—Erweiterung stoppen Veto: kein weiterer Datenträger Default: Rechen-/Parallelitäts-Engpass
storage

Mechanismus: APFS Copy-on-Write kann dazu führen, dass gelöschte große Verzeichnisse den angezeigten freien Speicher nicht sofort zurückgeben—besonders bei lokalen Snapshots. Governance muss Snapshot-Inventur enthalten; sonst führt „200GB gelöscht, df nur 20GB zurück“ zu falscher Erweiterungsentscheidung.

6-Schritte-Runbook: vom Sampling zur unterschriebenen Dreier-Wahl

  1. Wasserstand-Baseline einfrieren. Gesamtkapazität, freier Prozentsatz, Mountpoints; Knoten-ID, Xcode-Version, letzter Cleanup-Commit (Skriptversion).
  2. Schichtweises du-Sampling (Top-12-Verzeichnisse). ~/Library/Developer, DerivedData, CoreSimulator, ~/.gradle, ~/Library/Containers usw.; CSV für Audit.
  3. Standard-Cleanup-Paket ausführen. Reihenfolge: DerivedData (aktuelles Scheme optional behalten), ungenutzte Simulator-Runtimes, hängende Docker-Images, alte Archives (Release-Verantwortliche bestätigen).
  4. 24h-Steigung erneut messen. Sinkt freier Speicher >3 Prozentpunkte/Tag ohne erklärbares Release, markieren Sie strukturelles Wachstum.
  5. Matrix-Zweig wählen. Cache-Governance / 1TB·2TB / zweite Maschine—nicht „Cleanup + Erweiterung + Extra-Maschine“ ohne Begründung parallel.
  6. FinOps-Notiz und Lease fixieren. Strukturell → Monats-/Quartals-Lease + Erweiterung; kurze Spitze → Tages-/Wochen-Lease zweite Maschine; Prüfdatum im Ledger.
bash
# Top-Verzeichnis-Sampling auf dem Remote-Mac (WORK-Pfad ersetzen)
export WORK="$HOME"
df -h /
echo "---- top dirs under Library/Developer ----"
du -hd 1 "$HOME/Library/Developer" 2>/dev/null | sort -hr | head -12
echo "---- DerivedData total ----"
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
echo "---- CoreSimulator ----"
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

Drei quantitative Schwellen für die Review (Konstanten durch Baseline ersetzen)

  • Cleanup-Ertrag. Standard-Paket soll mindestens 18 % des aktuell belegten Speichers freigeben; unter 12 % ist Wachstum strukturell—Erweiterungs-/Zweitmaschinen-Matrix statt wiederholter Bereinigung.
  • Freispeicher-Rotlinie. Produktions-Build-Host: ≥20 % frei halten; unter 15 % kein volles Archive plus parallele UI-Tests (Gate-Felder mit POC-Skalierungs-KPI-Matrix teilen).
  • IO-Check nach Erweiterung. Innerhalb 48h nach 1TB/2TB: median busy% <25 % ohne Build-Zeitverbesserung → Option „mehr Datenträger“ in Review schließen, CPU/Speicher und Artefakt-RTT prüfen.

Abschluss: Architektur-Split nicht hinter „noch eine Platte“ verstecken

Bei sechs Regionen geht es darum, inkompressible Working Sets von kompressiblen Caches zu trennen. Rückgewinnbar → Governance; nicht rückgewinnbar → Erweiterung oder Aufteilung; nicht rückgewinnbar und Rechenleistung voll → kein weiterer Datenträger—nur Trost für Warteschlangen-Engpässe.

Selbst gehostete Macs oder kurzlebige Cloud-Instanzen trennen „Datenträger“ und „Betrieb“ auf zwei Rechnungen; Teams unterschätzen Snapshots, Simulator-Assets und geteilte Platten. Laptop-Build-Relais trifft in Release-Wochen Datenträger und Schlafrichtlinien gleichzeitig. Wer dediziertes Apple Silicon, planbare Datenträger-Tiers und sechs Regionen braucht, aligniert mit dieser Matrix und MACCOME Mac-Cloud 1TB/2TB plus Lease oft günstiger als Ad-hoc-Erweiterungen—CI und On-Call sprechen dieselbe Wasserstand-Sprache. Datenschutz (DSGVO) und Verfügbarkeit bleiben im Betriebsvertrag dokumentiert.

Nach Festlegung von Erweiterung oder zweiter Maschine Region und Lease-Positionen in dieselbe Review bringen. Preise und Zyklen auf der Produktseite; Stabilitätsabnahme und Monorepo-Artikel als Anhang, damit Release-Woche Kapazität und Pipeline gemeinsam diskutiert.

FAQ

Nach DerivedData-Löschung ist der Datenträger noch voll—Erweiterung oder zweite Maschine?

Fällt freier Speicher innerhalb von sieben Tagen wieder unter 15 % und dominieren Developer-Unterverzeichnisse in du, prüfen Sie 1TB/2TB mit Monats-Lease. Bei gesättigten CPU-/Speicher-Warteschlangen zweite Maschine laut Build-Pool-Artikel. Tier und Preise: Mac-mini-Mietpreise.

Builds bleiben nach 2TB-Erweiterung langsam—Datenträgerproblem?

Nicht zwingend. Bei idle IO und langsamer Kompilierung Stabilitätsabnahme und Architektur-Matrix nutzen. Details im Hilfe-Center.