Apple Silicon Cloud-Mac-Runner: Speicher-Spitzen & Swap-Steuerung — Kompilieren, Docker & Xcode gemeinsam: Kennzahlen, Absenkung & RAM-Grenzen der Tarife

1. Warum Spitzen sich stapeln: Compiler, Container und Xcode

Native Compiler reservieren große AST-Graphen und parallele Codegen-Arenen, wenn Job-Zähler Richtung Kernzahl gedreht werden. Docker Desktop oder Colima addieren Virtualisierungsseiten, Overlay-Caches und mitunter Rosetta-Helfer, wenn amd64-Images in Apple-Silicon-Pipelines rutschen. Xcode legt Modulgraphen, Swift Explicit Modules und ausführliche Diagnostik obenauf, wenn die CI ausführliche Indexierung aktiviert oder Desktop-Schemes übernimmt.

Keines davon ist „falsch“ — es sind gleichzeitige Ansprüche auf denselben Unified-Memory-Pool. Cloud-Runner verstärken das Muster, weil Release-Züge, nächtliche Fuzz-Jobs und containerisierte Integrationstests auf einem Host gebündelt werden. Das Versagensbild ist kein gleichmäßiges OOM, sondern minutenlanger Swap-Churn, der die Wandzeit über Job-Timeouts streckt und sich als flatterndes Netz oder hängende Simulatoren tarnt.

Container-Geländer und Speicherdeckel gehören zusammen — siehe Produktions-Docker auf Apple-Silicon-Cloud-Mac: arm64/amd64-Images, Bind-Mounts & Build-Cache — Fehlerbehebungs-Handbuch (mit Tarif-Grenzen) für Image-Klassen, die versehentliche Multi-Arch-Explosionen vermeiden.

2. Observability bei SSH-only-Zugang

Drei Ebenen instrumentieren: Host-Integrale, prozessverdächtige und Container-Budgets. Auf dem Host vm_stat für Pageouts und Compressor-Statistik samplen; bei unterstützten Builds memory_pressure in Soak-Fenstern dazunehmen. Swapfile-Fußabdruck getrennt von generischen „Speicher belegt“-Graphen führen — Apple Silicon komprimiert aggressiv; Swap ist ein verzögertes, aber entscheidendes Signal, dass Parallelitätsannahmen gebrochen sind.

Bei Docker docker stats-RSS und Limits während repräsentativer Pipelines auslesen; Limits mit Kompilier-Parallelität im Container ausrichten, damit der Kernel nicht zwischen cgroup-Drossel und hostweitem Swap pendelt. Für Xcode-lastige Phasen Spitzen-RSS bei Derived-Data-Strategien loggen; inkrementelle Builds verringern Platten-Churn, können aber große RAM-Caches zwischen Schemes halten.

Platten-Druck drückt indirekt über Cache-Eviction auf den RAM — Inodes und SSD-Puffer mit Apple Silicon Cloud-Mac-Runner: Speicher, Inodes, Derived Data & Docker im Gleichschritt halten, damit Wartungsjobs nicht mit Builds um I/O und Speicherbandbreite konkurrieren.

Für iOS-/macOS-Pipelines (codesign, Notarization, Schlüsselbund) dieselbe Disziplin bei Warteschlangen und Geheimnissen wie in Apple-Silicon-Cloud-Mac: iOS/macOS-CI, codesign, Notarization, stapler & Schlüsselbund — Speicher-Spitzen verschärfen dort ohnehin zeitkritische Schritte.

# Leichtgewichtiger Sampling-Hook (als CI-Diagnose-User)
vm_stat | head -n 20
sysctl vm.swapusage
docker stats --no-stream 2>/dev/null || true

3. Absenkungs-Playbook, wenn Telemetrie gelb blinkt

Schwere Phasen serialisieren: Volles xcodebuild archive nicht parallel zu mehrstufigen Docker-Builds auf RAM-knappen Tarifen planen, solange Limits ohne Messung keine Sicherheit belegen.

Parallelität klemmen: Swift-/clang-Jobs unter Kernezahl senken, wenn Container aktiv sind; deterministisches -j aus sysctl hw.ncpu minus fester Reservation für Agents.

CI-Matrizen sharden: UI-Tests, Backend-Integration und Packaging in getrennte Queue-Stufen statt eines Mega-Graphen — Wandzeit steigt leicht, aber Schweif-Latenzen kollabieren.

Native arm64-Images bevorzugen und qemu-lastige Pfade stutzen; Emulation multipliziert Speicher und unerwartete Helfer. Kleinere Build-Kontexte, damit BuildKit keine riesigen Zwischenlayer im RAM hält.

4. RAM-Grenzen der Tarife und Puffer-Rechnung

kvmboot betont 16 GB Unified Memory mit Einstiegs-SSD-Größen und 24 GB in größeren Paketen (siehe Tarife und Spezifikationen). Abziehen: rund 4–6 GB für macOS, Desktop-Dienste, Monitoring und SSH; weiteres Gigabyte, wenn Bildschirmfreigabe oder Remote-GUI für Debugging aktiv bleibt.

Was übrig bleibt, ist das Parallelitätsbudget. Ein großes iOS-Archiv kann beim Linken zweistellige Gigabyte RSS erreichen; zwei moderate Docker-Dienste dazu — und ein 16-GB-Tarif ist ohne Böswilligkeit voll. Der 24-GB-Tarif kauft Spielraum für überlappende Phasen oder Teams, die Archive nicht serialisieren wollen, aber planbare Swap-Ränder erwarten.

Warteschlangenökonomie und Spitzenlast hängen zusammen — Profile, Risikostufen und Mandantenquoten für Runner diskutieren wir im OpenClaw-Kontext unter OpenClaw Ausführungsrichtlinie & Runner-Profile: Risikostufen-Routing, Mandantenquoten, menschliche Gates, wenn entschieden werden soll, ob mehr Parallelität über breiteres RAM oder zusätzliche Runner kommen soll.

5. Symptom — Ursache — Maßnahme

6. Fazit

Swap auf Apple Silicon ist kein moralisches Versagen — es ist ein Scheduling-Signal. Überschneidende Compiler, Container und Xcode als konkurrierende Mieter auf Unified Memory behandeln, vor Nutzerbeschwerden instrumentieren und Spitzen mit dem gebuchten RAM-Tarif statt mit dem Wunsch-Workstation ausrichten.