OpenClaw-Gateway bei 100 Prozent CPU: Der Metadaten-Fix greift nicht immer

96,5 Prozent nach sieben Minuten, später 99,1 Prozent — so beschreibt ein OpenClaw-Fehlerbericht vom 26. August 2026 (Issue #130324) einen Gateway-Prozess, der einen kompletten Kern belegt. Dazu kommen laut demselben Bericht wiederholte Stalls des Node.js-Event-Loops von 32 bis 54 Sekunden. Das ist keine Nuance mehr. Ein Prozess, der so lange nicht auf den Loop zurückkommt, beantwortet in dieser Zeit auch keine Dashboard-, Status- oder Session-Anfrage.

Der aktuelle Fall lässt sich nicht wegupdaten

Die unangenehme Pointe von Issue #130324: Das Verhalten bleibt auf aktuellem Main bestehen, nachdem über den unterstützten Source-Update-Weg aktualisiert und vollständig neu gebaut wurde. Eine veraltete Installation erklärt diesen konkreten Fall damit nicht. Wer nach einem Update einen Kern auf Anschlag sieht, kann das Problem also nicht durch ein weiteres Update wegräumen.

Der Bericht formuliert die Erwartung ausdrücklich: kein dauerhaft voller CPU-Kern und keine Blockade über Dutzende Sekunden, weder im Leerlauf noch bei Dashboard-Status- und Session-Anfragen. Das ist eine konservative Untergrenze für einen Dienst, der diese Anfragen zuverlässig bearbeiten soll. Auf dem Spiel steht die Reaktionsfähigkeit größerer Setups, denn ein blockierter Event Loop trifft alle Anfragen gleichzeitig.

Die Spur führt zu den Plugin-Metadaten — vorerst

Ähnliche Symptome sind in OpenClaw dokumentiert. Laut Issue #118846 vom 3. August 2026 stand der Hauptthread in einem P1-Fall ab Prozessstart durchgehend bei rund 100 Prozent eines Kerns; das dort erstellte CPU-Profil schrieb den Großteil der Eigenzeit Plugin-Metadaten-Snapshots und Dateisystem-Stat-Aufrufen zu. Zwei Wochen später hielt ein Maintainer-Issue vom 18. August 2026 (#125595) einen Event-Loop-Stall von 75,97 Sekunden fest, zusammen mit wiederholten Rebuilds ebendieser Plugin-Metadaten. Drei Berichte in gut drei Wochen zeigen dasselbe Muster: hohe Grundlast, lange Blockaden, ein Pfad, der offenbar zu oft und zu teuer läuft.

Bewiesen ist die Verbindung damit nicht. Issue #130324 ordnet die CPU-Zeit keiner Ursache zu, sondern beschreibt Symptome, die zu einer bekannten Baustelle passen. Als Arbeitsannahme trägt die Metadaten-Spur, weil sie die drei Fälle verbindet — ein anderer Ausführungspfad könnte sie kippen, und im eigenen Setup ersetzt sie die Messung nicht.

Was Betreiber jetzt konkret tun

Nach jedem Update den Gateway-Prozess über mehrere Minuten beobachten, statt nur den Start abzuhaken: CPU-Auslastung pro Prozess mitschreiben und die Event-Loop-Latenz erfassen. In Issue #130324 sanken die Werte über den Beobachtungszeitraum nicht ab — genau dieser Verlauf ist das Signal, nicht der einzelne Spitzenwert.

Wer einen Befund hat, sollte ihn belastbar festhalten: Zeitpunkt, Version beziehungsweise Commit, gemessene CPU-Last, längster Stall und die Frage, ob der Prozess im Leerlauf oder unter Anfragen stand. Diese vier Angaben sind das, was die bestehenden Issues auswertbar macht.

Die Eskalationsgrenze ist ebenfalls klar: Wenn die Blockaden über den Beobachtungszeitraum bestehen bleiben und Anfragen sichtbar auflaufen, hört Beobachten auf zu genügen. Dann gehört ein CPU-Profil des laufenden Prozesses erstellt — so ist die Metadaten-Spur in Issue #118846 überhaupt erst sichtbar geworden — und parallel der Rückweg auf einen zuvor unauffälligen Stand geprüft. Ein Kern auf Anschlag ist kein Kosmetikproblem, denn dieselbe Blockade greift, sobald echte Anfragen ankommen.