Gateway start quiet slow

[tawny crag]

Ich habe seit Tagen das Problem, dass das Gateway fast 2 Minuten benötigt, um zu starten, obwohl nur ein Telegram-Channel eingerichtet ist. Hast du noch einen Rat für mich?

Deutlich besser als vorher: Wir haben die Bremse jetzt exakt lokalisiert.

Was ich gefunden habe:

Der langsame Start kommt nicht von allgemeinem .openclaw-Müll, sondern vor allem von zwei konkreten Startup-Phasen:

sidecars.channels = 69.1s
sidecars.plugin-service = 26.7s

Zusammen macht das praktisch die komplette Wartezeit aus:

sidecars.total = 95.8s
ready gesamt = 105.2s

Wichtig:

Der Gateway ist also nicht einfach generell träge. Es sieht eher so aus:

1. Der Channel-Startup benötigt ca. 69 Sekunden.
2. Die Plugin-Services benötigen danach noch einmal ca. 27 Sekunden.

Das erklärt, warum es sich nach jeder Änderung so anfühlt, als müsste ich fast 2 Minuten warten.

Was Cleanup angeht:

Der Ordner ~/.openclaw ist bei mir ca. 1,7 GB groß. Der größte Teil davon ist:

plugin-runtime-deps = 1.5G

Das ist zwar viel, scheint aber nicht die Hauptursache für den langsamen Post-Attach-Start zu sein.

Cleanup wäre vermutlich sinnvoll, aber wahrscheinlich nicht der eigentliche Fix.

Noch ein wichtiger Punkt:

openclaw status ist weiterhin selbst langsam:

openclaw gateway status ≈ 2.46s
openclaw status ≈ 50.59s

Das scheint ein separater Schmerzpunkt zu sein.

Mein Fazit:

Wir haben jetzt zwei klare Verdächtige:

Channels
Plugin Services

Nächster sinnvoller Schritt:

Ich würde gerne die Plugin-Services weiter aufdröseln, damit sichtbar wird, welcher konkrete Service die 26,7 Sekunden verursacht.

Danach wäre es sinnvoll, den Channel-Startup noch genauer zu untersuchen, um herauszufinden, warum ein einzelner Telegram-Channel ca. 69 Sekunden benötigt.

Das ist jetzt nicht mehr blindes Suchen, sondern eher das gezielte Freilegen des konkreten Übeltäters.

[buoyant delta]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[cursive leaf]

Ja — das ist jetzt gut eingegrenzt. Zwei nächste Tests:

0) Bitte zuerst Version posten:

openclaw --version

Gerade bei Gateway/Telegram/Status gab es viele Änderungen, daher ist die Version hier entscheidend.

1) Plugin-Services: Browser-Control als Verdächtigen testen

Der gebündelte Browser-Plugin ist standardmäßig aktiv, und Plugin-Services laufen beim Gateway-Start mit. Teste einmal reversibel:

openclaw plugins inspect browser

openclaw plugins disable browser
openclaw gateway restart

Dann erneut Startup-Zeiten messen. Danach wieder zurück:

openclaw plugins enable browser
openclaw gateway restart

Wenn sidecars.plugin-services dann von ~27s auf fast 0 fällt, haben wir den Übeltäter. Die Plugin-CLI kann list/inspect/enable/disable, und der Browser-Plugin ist ein gebündelter Default-Plugin. (docs.openclaw.ai)

2) Telegram-Startup gezielt mit HTTP-Diagnostik laufen lassen

Am besten einmal foreground statt Service:

openclaw gateway stop

OPENCLAW_GATEWAY_STARTUP_TRACE=1 \
OPENCLAW_DIAGNOSTICS=telegram.http \
openclaw gateway run

gateway run ist der Foreground-Start, und OPENCLAW_GATEWAY_STARTUP_TRACE=1 loggt Startup-Phasen. (docs.openclaw.ai)
OPENCLAW_DIAGNOSTICS=telegram.http aktiviert gezielte Telegram-HTTP-Logs; die landen standardmäßig in /tmp/openclaw/openclaw-YYYY-MM-DD.log. (docs.openclaw.ai)

Dann im Log nach diesen Begriffen schauen:

rg "telegram|deleteWebhook|setMyCommands|getMe|getUpdates|timeout|network|fetch" /tmp/openclaw/openclaw-*.log