2026 OpenClaw sur Mac Mini loué : état d’agent en SQLite WAL, checkpoints planifiés et dégradation thermique des files — guide opérable 7×24

Les équipes qui louent un Mac Mini pour faire tourner OpenClaw toute la nuit veulent un état d’agent fiable sans Postgres lourd : SQLite en WAL est tentant, mais sans cadence de checkpoint ni file bornée, la thermique ou un disque qui se tend transforme une charge banale en cascade de timeouts.

« Ce guide condense schéma minimal, PRAGMA utiles, launchd pour checkpoints passifs, corrélation caffeinate / thermique avec réduction de concurrence, et une matrice de seuils pour WAL, busy_timeout, inodes et backoff — le tout orienté observabilité 7×24. »

Poursuivez avec le guide Healthchecks.io, la matrice SQLite WAL générique et la série OpenClaw sur le blog.

Trois frictions qui cassent une persistance SQLite « simple » sur Mac loué

1. WAL sans discipline. Un fichier -wal qui grossit indéfiniment retarde les lectures froides et masque la saturation inode réelle jusqu’au dernier moment.
2. Concurrence mal bornée. Plusieurs workers qui écrivent des sessions longues créent des busy en rafale ; sans busy_timeout cohérent, OpenClaw interprète à tort une panne applicative.
3. Thermique ignorée. Quand le nœud réduit la fréquence, une file profonde amplifie la latence ; il faut un contrat de dégradation qui rétrécit les slices actifs avant l’escalade humaine.

Sept étapes reproductibles : schéma, launchd, thermique et slices

1. Schéma SQLite minimal pour sessions d’agent. Colonne slice_id, horodatage, état JSON compressé ; index sur (slice_id, updated_at).

   PRAGMA journal_mode=WAL;
   PRAGMA synchronous=NORMAL;
   PRAGMA busy_timeout=5000;
   PRAGMA foreign_keys=ON;
   
   CREATE TABLE IF NOT EXISTS agent_sessions (
     id TEXT PRIMARY KEY,
     slice_id TEXT NOT NULL,
     state_json BLOB NOT NULL,
     updated_at INTEGER NOT NULL
   );
   CREATE INDEX IF NOT EXISTS idx_sessions_slice
     ON agent_sessions(slice_id, updated_at);

2. Initialisation fichier. Placez la base sous un répertoire dédié ~/openclaw/state avec quotas de logs séparés pour ne pas confondre croissance WAL et journaux applicatifs.
3. launchd pour checkpoint passif. Programmez un appel sqlite3 /chemin/état.db "PRAGMA wal_checkpoint(PASSIVE);" toutes les cinq minutes la nuit ; gardez ThrottleInterval pour éviter tempêtes si le disque sature.
4. caffeinate et charge nocturne. Encadrez le daemon OpenClaw avec caffeinate -dimsu seulement si votre charte d’exploitation l’autorise ; journalisez début et fin pour corréler avec les métriques SQLite.
5. Boucle thermique légère. Un script launchd trente secondes lit un indicateur grossier (charge CPU lissée ou sortie filtrée de pmset -g thermlog) ; au-delà d’un seuil convenu, réduisez la profondeur de file côté passerelle OpenClaw et augmentez légèrement le backoff.
6. Liaison OpenClaw. Documentez un drapeau local « mode dégradé » consommé par votre passerelle : moins de slices parallèles, transactions plus courtes, flush des états non critiques vers un second fichier SQLite si besoin.
7. Sharding par slice. Pour isoler les hot spots, partitionnez par hash(tenant) % N sur N bases ; un checkpoint par base reste rapide et simplifie les restaurations partielles.

Observabilité 7×24 : ce que la supervision distante doit voir avant l’incident

Exportez en JSONL les durées de transaction, le ratio pages WAL / taille base, et la profondeur de file ; corrélez avec les pings décrits dans le guide heartbeat 7×24.

• Histogramme busy SQLite par tranche d’une heure, lissé sur trois nuits.
• Taille WAL et marge inode sur le même graphe multi-axes pour éviter les fausses vertes.
• Compteur de bascules « thermique → dégradé » avec identifiant de build OpenClaw figé.

FAQ : verrous et disque plein