2026 Mehrregionen Mac mini M4 Parallel-Cluster
SQLite WAL auf Freigaben: Checkpoints, parallele Builds, I/O-Jitter, Buildsperren & 1TB/2TB-Abnahme

Warum WAL auf Freigaben I/O besonders „beißt“

Für Teams mit mehreren dedizierten Mac-CI- und Cache-Knoten über Regionen hinweg: klare Grenzen für Speicher-Topologie × SQLite, ausführbare PRAGMA-/journal_mode-Skripte, eine konservative Obergrenze für Warteschlangen-Parallelität sowie eine 1TB/2TB-Abnahme-Checkliste. Vertiefung und gleiche Runbook-Sprache finden Sie in Nomad-Affinität & Buildsperre, rsync-Artefakt-Matrix, Watchman, FSEvents & Disk-Schwellen und Mosh vs. SSH & flock.

Latenz zwischen AZs addiert sich zu jedem fsync-artigen Schritt: Was auf lokaler APFS noch im Mikrosekundenbereich liegt, wird auf SMB/NFS zum wiederkehrenden Jitter — gerade wenn große Link-Schritte oder Xcode-DerivedData parallel laufen. Daher zuerst Parallelität drosseln, bevor Sie synchronous lockern.

• WAL-Schreibverstärkung: -wal- und -shm-Dateien liegen neben der Haupt-DB; jede Transaktion erzeugt mehr Netzwerk-Roundtrips als auf lokaler SSD.
• Checkpoint-Resonanz: Beim Zurückschreiben von WAL-Seiten konkurrieren Checkpoints mit großen Build-Artefakten um Bandbreite und Metadaten-IOPS auf derselben Freigabe.
• Sperren & Scheduler: Ohne abgestimmte busy_timeout-Werte und Backoff-Strategien stauen sich Jobs in der Queue — sichtbar als P99-Spikes, nicht als CPU-Last.

Entscheidungsmatrix: Topologie × SQLite-Nutzung

Standardempfehlung: Datenbankdateien auf lokaler SSD halten. Nur wenn ein Freigabe-Pfad unvermeidbar ist: genau ein Schreiber und die folgenden Parallelitäts-Bandbreiten einhalten.

Ausführbare PRAGMA- und journal_mode-Empfehlungen

Auf lokaler SSD einmalig Journal-Modus und Synchronisationsstufe setzen; auf Netzwerk-Freigaben zuerst Sperr-Semantik und Risikoabnahme mit Stakeholdern klären.

Skript z. B. als init_ci_cache_db.sh, Pfad über CI_SQLITE_PATH:

#!/usr/bin/env bash
set -euo pipefail
DB="${CI_SQLITE_PATH:?}"
sqlite3 "$DB" <<'SQL'
PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;     -- bei strengerer Durabilität: FULL
PRAGMA wal_autocheckpoint=1000;
PRAGMA busy_timeout=8000;
PRAGMA foreign_keys=ON;
PRAGMA cache_size=-64000;      -- ca. 64 MiB Page-Cache, an RAM anpassen
SELECT sqlite_compile_option_used('THREADSAFE');
PRAGMA journal_mode;           -- Erwartung: wal
PRAGMA user_version;
SQL

Fällt journal_mode=WAL auf delete zurück oder schlägt fehl, liegt meist ein Pfad- oder VFS-Problem vor — dann Datenbank migrieren oder Topologie ändern, nicht die Parallelität erhöhen. wal_checkpoint(TRUNCATE) nur im Wartungsfenster ohne andere Schreiber, damit die WAL-Datei nicht den Disk-Wasserstand unnötig anheizt.

Warteschlangen-Parallelität und I/O-Jitter

Kalibrieren Sie Startwerte mit iostat, Build-P99 und SQLite-busy-Zählern — nicht nur CPU:

• Gleiche Freigabe, gleicher Schreibbaum: 1–2 gleichzeitige aktive Schreib-Builds (auf 1TB eher 1, auf 2TB vorsichtig 2 testen). Zuerst Queue-Parallelität senken, nicht synchronous lockern.
• Promote / Golden-Image: Entweder max_parallel = 1 im Orchestrierer oder flock als autoritative Quelle — nicht beides widersprüchlich.
• Lokal pro DB-Datei: Harte Obergrenze für „mehrere Writer auf dieselbe Datei“, um Hotspots zu vermeiden.

Steigen P99 und die WAL-Dateigröße: zuerst Parallelität und Schreibverstärkung adressieren, dann erst über größere SSDs oder getrennte Freigaben nachdenken.

Buildsperre und WAL-Lebenszyklus

Vor Migration, großem VACUUM oder manuellem Checkpoint: flock auf ein lokales Lockfile (nicht auf die Freigabe selbst legen). Ist der Scheduler ohnehin strikt serialisiert, kurze Lock-Timeouts und schnelles Fail statt endloser Retry-Schleifen.

LOCK_FILE="/var/tmp/ci-sqlite-maint.lock"
flock -w 30 "$LOCK_FILE" sqlite3 "/Volumes/shared/ci_meta.db" \
  "PRAGMA wal_checkpoint(PASSIVE);"

1TB/2TB-Disk-Abnahme (inkl. SQLite & Queues)

Anbindung an Scheduling und Artefakt-Fan-out

Artefakt-Bäume bleiben beim Muster „ein promote, ein rsync-Profil“; die Wasserstände aus diesem Artikel in dasselbe Runbook wie rsync-Matrix und Nomad-Buildsperre übernehmen.

FAQ

Viele CLIs schreiben gleichzeitig WAL über SMB? Nicht empfohlen — pro Maschine eigene DB oder ein dedizierter Schreibdienst.

PRAGMA synchronous=OFF? Senkt Latenz, vergrößert das Korruptionsfenster; nur für vollständig rekonstruierbare Cache-DBs und mit dokumentiertem Restrisiko.

Wie oft checkpointen? Abhängig von WAL-Wachstum; auf Freigaben selten TRUNCATE, in Ruhephasen PASSIVE plus weniger parallele Schreiber.

Wann wal_checkpoint(TRUNCATE)? Nur im genehmigten Fenster ohne andere Schreib-Verbindungen, wenn WAL und Speicherfüllung es erzwingen — siehe JSON-LD-FAQ.