Sie betreiben bereits OpenClaw Gateway und stdio MCP, sehen in Produktion aber langsam steigende Kindprozesszahlen, steigenden RSS oder gelegentliche OOM und sind unsicher, ob Konfiguration oder Architektur angepasst werden soll. Dieser Artikel ergänzt MCP stdio/HTTP-Handshake und Hänger sowie Gateway-Produktions-Monitoring: zuerst sieben Grenzen, dann eine stdio-vs.-HTTP-Betriebstabelle, anschließend ein sechsstufiges Reclaim- und Drosselungs-Runbook sowie Hinweise zu Umgebungsvariablen und Neustart unter systemd/Docker; am Ende Links zur OpenClaw-Übersicht und zu Compute-Szenarien.
Für stdio-MCP Verbindungs-Handshake, Hänger, Berechtigungsfehler zuerst Handshake-Troubleshooting; für Allowlists und Tool-Richtlinien MCP-Toolchain-Allowlist; für Healthchecks, Logs, Upgrade/Rollback Monitoring. Dieser Text beantwortet nur: Wenn das Gateway Sitzungen stabil annimmt, Kindprozesse und Speicher kurven aber unannehmbar bleiben, wie Sie in Schichten steuern.
Erster Handshake fehlgeschlagen: MCP-Transport und ausführbare Downstream-Pfade prüfen; hier nicht ausgeführt.
Token/Scope und gateway closed (1000): dedizierter closed(1000)-Artikel, nicht Reclaim-Skripte ändern.
Reine Sicherheitsrichtlinie: Änderungen an dmPolicy / networkPolicy im Hardening-Artikel.
Gateway startet nicht / not ready: Ports, Speicher, Compose-Reihenfolge im Not-ready-Artikel.
App-Layer-Model-Backend-Timeouts: parallel zu MCP-Subprozessen, Ursache kann Routing sein.
Einmalige Lecks durch Drittanbieter-MCP-Bugs: Upstream-Fix oder Version pinnen; Reclaim mildert nur.
„Aufräumen“ als Allheilmittel: Harte Kills ohne Pegel und Versionsbuchführung verdecken echte Lecks.
In der Community wird diskutiert, dass stdio MCP als Gateway-Kindprozesse bei langen Sitzungen den Pool mitwachsen lassen können; das Verhalten ändert sich je Release. Betrieb sollte „akzeptable Prozessobergrenze + Reclaim-Richtlinie“ im Runbook festhalten statt Defaults zu vertrauen. Zuerst das Modell Sitzungsisolierung → erwartbarer Anstieg, dann die Tabelle.
Schnittmenge mit dem Handshake-Artikel: Fehler zeigen Verbindungs-/Handshake-Fehler in Logs; typische Signale hier sind monoton steigende Prozesszahlen, stufenförmiger Speicheranstieg, OOM in festem Takt. Bei der Analyse Eltern-Kind zwischen Gateway und MCP prüfen (ps / Container-pstree), damit Model-Backends oder Kanalprozesse nicht als MCP zählen.
Bei mehreren Toolchains (lokale Skripte plus dauerhafte Agenten auf einem Remote-Mac) Topologie skizzieren: Welcher Host führt Gateway, welcher schwere MCP aus? Der Speicher-Headroom des Gateway-Knotens begrenzt parallele stdio-Sitzungen. Kapazität und Zugang: Mietpreise mit Netzanforderungen aus dem Hilfezentrum kombinieren.
Für Observability mindestens drei Zeitreihen: Prozesszahl, RSS von Gateway und MCP, Tool-Call-QPS und Sitzungszahl. Ohne Sitzungsdimension ist „Anstieg“ nicht von Lastspitzen oder fehlendem Reclaim zu trennen. Logfelder mit Monitoring angleichen, sonst bleibt Nur-Restart nach Bauchgefühl.
Häufiges Missverständnis: „Viele Kinder = HTTP“. Sind Tools sehr leicht und Parallelität niedrig, liegt es eher an nicht geschlossenen Sitzungen oder blockierenden Downstream-Binaries; zuerst Client-Lebenszyklen straffen, dann Transportkosten kalkulieren.
stdio-Transport koppelt den MCP-Server als Kindprozess eng an das Gateway; HTTP-Transport wirkt eher wie ein eigenständiger Endpunkt mit anderem Skalierungs- und Healthcheck-Pfad. Die Tabelle unterstützt die Entscheidung „stdio weiter optimieren“ oder „HTTP“.
| Dimension | stdio MCP | HTTP MCP |
|---|---|---|
| Prozesskopplung | Kinder folgen Gateway/Sitzungsmodell; Anstieg fällt auf | Oft eigener Prozess, Gateway ist Client |
| Horizontale Skalierung | Oft Gateway mit skalieren oder Sitzungen drosseln | MCP-Dienst replizierbar |
| Healthchecks | Gateway-Logs und Prozesstabelle | HTTP-Sonden und eigenes SLO |
| Blastradius | Kindprobleme bremsen Gateway auf demselben Host | Bessere Isolation, zusätzlicher Netz-Hop |
| Passende Fälle | Leichte Tools, geringe Last, vertrauenswürdig gleicher Host | Schwere Tools, hohe Last, eigenes Release |
„Governance“ heißt nicht unendlich Hardware, sondern einen Vertrag für Prozess- und Speicher kurven: darüber hinaus drosseln, reclaimen oder den Transport wechseln.
Wenn stdio/HTTP-Handshake die Konfiguration bestätigt, die Speicherlinie aber dauerhaft rot bleibt, „HTTP-ify“ in die Architekturreview stellen statt Hosts endlos zu vergrößern.
Reihenfolge: „Beweise, Drosselung, Architektur“. Logfelder wie in Monitoring, keine blinden Kills.
Baseline: unter stabiler Last Prozesszahl, RSS, Gateway- und MCP-Paketversionen im Änderungslog festhalten.
Spitzen vs. Lecks: Spitzen korrelieren oft mit parallelen Sitzungen; monotones Wachstum deutet auf fehlenden Reclaim oder hängenden Downstream—Stacks sichern.
Parallelität und Timeouts straffen: innerhalb der Konfiguration parallele Tool-Calls senken, Idle-Timeouts verkürzen, Kurven beobachten.
Geplantes Reclaim: im Wartungsfenster Gateway rollierend neu starten oder Knoten isolieren, zuerst Sitzungen drainen.
Container und systemd: prüfen, ob Umgebungsvariablen in der echten Laufzeit ankommen (Daemon vs. interaktive Shell).
HTTP-Migration bewerten: schwere MCP oder eigenständig skalierbare Dienste separat deployen, Healthchecks setzen, Gateway auf HTTP-Transport umstellen.
ps -axo pid,ppid,rss,comm | grep -E 'openclaw|mcp|node' | head -n 50 # Im Container mit pstree -p 1 für Eltern-Kind
Hinweis: Nach Änderungen an openclaw.json die empfohlenen Validierungsbefehle (z. B. config:validate / doctor) ausführen, dann rollierend neu starten, damit nicht „Konfiguration wirkt gesetzt, Prozesse nutzen alte Werte“.
Öffentliche Issues melden „stdio-MCP-Kinder werden bei Sitzungswechsel nicht reclaimed“; betrieblich periodisches Reclaim + Versionsverfolgung als Übergang, Upstream-Fix einplanen. Nicht dauerhaft auf undokumentiertes manuelles kill setzen.
Bei Sidecar-Reclaim (systemd-Timer, k8s CronJob) Gateway-Benutzer, Umgebung und cgroup-Speicherlimits angleichen, sonst weichen Prozessbäume von Produktion ab. Auf kleinen Einzelknoten zuerst Parallelität und Timeouts in den Vertrag drücken, dann Sidecar-Komplexität.
Jede Reclaim- oder Drosselungsänderung mit einer Release-Version verknüpfen; stdio-Verhalten kann sich zwischen Gateway-Minors ändern.
systemd-Units erben keine interaktive ~/.zshrc. Unter Docker Compose können MCP-Pfade und Read-only-Mounts Kinder in einer Neustartschleife halten. Mit Docker-Produktion Environment=, WorkingDirectory=, benannte Volumes und Image-Digest prüfen.
Achtung: Häufiges docker compose restart ohne vorherigen Exit-Code verwechselt Konfigurationsfehler mit Speicherleck.
Zusammen mit not-ready-Troubleshooting: bei Speichermangel erreicht das Gateway ggf. keine stabile MCP-Phase—zuerst Ressourcen und Startreihenfolge.
Die folgenden Größen sind übliche Startpunkte; an die reale Last anpassen.
Agent und Gateway auf einem kleinen, instabilen Knoten erzeugen „Doppel-Wackeln“ von Toolchain und Modell; nur Hardware nachzulegen ohne Sitzungsmodell zu ändern, skaliert Kosten linear. Teams, die dauerhaft online, planbare Rechenleistung für macOS-Builds oder Automatisierung brauchen und Reserve für OpenClaw-nahe Toolchains wollen, profitieren oft von NodeMini Mac Mini Cloud-Miete mit festem SSH und klaren Specs gegen zusammengewürfelte Laptops oder überbuchte Shared-Hosts: Mietpreise und Hilfezentrum für Netz und Zugang.
„stdio-Sitzungsobergrenze + Reclaim-Richtlinie + HTTP-Migrationsauslöser“ auf einer gemeinsamen Betriebsseite festhalten, damit Entwicklung und SRE dieselben Metriken prüfen.
Externe Postmortems mit Prozesssnapshots und Logauszügen absetzen, um Fehlkonfiguration von Upstream-Defekten zu trennen.
Nicht unbedingt. Erwartetes Wachstum durch Sitzungsisolierung von leckartigem Anstieg trennen, RSS und Gateway-Version mit bekannten Problemen abgleichen; bei Bedarf auf eine Fix-Version upgraden statt nur Cron hinzuzufügen.
Wenn sich Lebenszyklen der Kinder langfristig schwer mit dem Sitzungsmodell alignen lassen oder der Speicher dauerhaft knapp bleibt und nicht horizontal skaliert werden kann, ist HTTP MCP oft einfacher unabhängig zu skalieren und zu health-checken. Hintergrund auch in der OpenClaw-Übersicht.
Zuerst Mietpreise für Stufenvergleich, dann Hilfezentrum für Netzwerk- und Zugang zur Kapazitätstabelle.