Titel: Hoher CPU-Verbrauch (~60%) mit v4.70.0 – behoben durch Downgrade auf v4.66.8

Konfiguration
1

Umgebung:

  • Gladys v4.70.0 (automatisch aktualisiert über Watchtower)

  • Docker auf Linux (Ubuntu), network_mode: host

  • MQTT-Integration mit mehreren Geräten (Raspberry Pis)

Problem:

Nach der automatischen Aktualisierung von Gladys von v4.66.8 auf v4.70.0 durch Watchtower begann der Container, ständig ~60% CPU zu verbrauchen – nicht nur beim Start, sondern dauerhaft.

gladys    59.72%

Die Logs zeigten beim Start eine Flut von Fehlermeldungen:

NotFoundError: DeviceFeature mqtt:xxx not found

Dabei handelt es sich offenbar um ein Timing-Problem, bei dem MQTT-Retained-Nachrichten eintreffen, bevor Gladys seinen Device-Feature-Cache geladen hat. Selbst nachdem die Startfehler aufgehört hatten und die Logs sauber waren, blieb die CPU bei ~60%.

Lösung:

Heruntergestuft auf v4.66.8 und die Version gepinnt, um zu verhindern, dass Watchtower automatisch aktualisiert:

yaml

gladys:
  image: gladysassistant/gladys:v4.66.8
  labels:
    com.centurylinklabs.watchtower.enable: "false"
```

Nach dem Herunterstufen sank die CPU sofort auf ~4%.
```
gladys    3.90%

Frage:

Ist dies ein bekanntes Problem mit v4.70.0? Gibt es Pläne, die CPU-Regression zu beheben? Ich möchte irgendwann aktualisieren, aber nicht, wenn die Leistung wieder leidet.

2

Hallo @bamboleate und willkommen im Forum!
Du musst ein Problem haben, denn bei mir gibt es seit Version 4.70 (und auch davor) keine CPU-Probleme:

image
image791×344 35.5 KB

Und ich habe Zigbee, Node-Red, Z-Wave und Szenen, die auf Gladys laufen.

Wie ist deine Hardware-Architektur, um Gladys zu betreiben? (CPU, RAM, HDD/SSD usw.)

3

Hi @mutmut, danke fürs Nachschauen!

Meine Hardware:

  • Gerät: Minisforum UM350 (AMD Ryzen 5 3550H)

  • RAM: 32 GB

  • Speicher: mehrere HDDs und SSDs angeschlossen

  • OS: Ubuntu 24.04

  • Docker, network_mode: host

Der CPU-Spitzenwert ist bei mir sehr reproduzierbar. Hier ist der Vergleich davor/nachher:

v4.70.0:

gladys    59.72%

v4.66.8 (selbes Gerät, selbe Konfiguration, selbe Zeit):

gladys    3.90%

Ich betreibe die MQTT-Integration mit 3 Raspberry Pis (Relaisplatine + Sensoren). Kein Zigbee, kein Z-Wave, Node-RED nutze ich jedoch.

Etwas, das mir beim Start mit v4.70.0 in den Logs aufgefallen ist:

NotFoundError: DeviceFeature mqtt:xxx nicht gefunden

Dies wiederholt sich für jedes MQTT-Gerätefeature bei jedem Start – sieht so aus, als ob die gespeicherten Nachrichten eintreffen, bevor der Gerätekache bereit ist. Könnte dieser Fehlerstrom den CPU-Spitzenwert verursachen? Vielleicht ist es spezifisch für MQTT-Setups?

4

Deine Hardware ist offensichtlich gut, ich bin auf einem Proxmox-Cluster und Gladys läuft in einem LXE (einfach ausgedrückt eine VM-Äquivalent) mit 6 GB RAM und 2 vCPU.

Ich bin leider kein Experte für eine detaillierte Analyse.
Allerdings, was die MQTT-Integration von Gladys betrifft, verwendest du die interne Integration?

image
image727×277 30.9 KB

Was sagt die Debug-Seite?

image
image772×609 49.3 KB

Falls du MQTT Explorer (zum Beispiel) verwendest, um dich mit dem MQTT-Broker zu verbinden, erscheinen dann Informationen von deinen RPi?

image
image401×403 28.3 KB

Ein weiterer Punkt, wie hast du deine Geräte in der MQTT-Integration konfiguriert?

image
image418×838 44.1 KB

image
image417×520 34.8 KB

Aus der Fehlermeldung, die ich sehe, wird ein (oder mehrere?) Gerät(e) nicht gefunden/erkannt. Man müsste mit MQTT Explorer prüfen, ob es sichtbar ist und ob die Konfiguration in der MQTT-Integration von Gladys noch korrekt ist.

5

Hi @mutmut, danke für die detaillierten Fragen!

Ja, ich verwende die interne MQTT-Integration in Gladys.

Was die NotFoundError-Meldungen betrifft: Ich habe dies bereits gründlich untersucht. Die Fehler treten nur beim Start auf und sind ein Timing-Problem – der MQTT-Broker liefert behaltene Nachrichten, bevor Gladys seinen Gerätefunktions-Cache vollständig geladen hat. Nach dem Start sind die Protokolle völlig sauber und alle Geräte funktionieren korrekt. Die RPis veröffentlichen korrekt, die Themen sind richtig und alles ist in MQTT Explorer sichtbar.

Die Fehler sind nicht die Ursache meiner Probleme – sie sind ein Symptom des Start-Timings. Und noch wichtiger: Die CPU bleibt bei ~60% permanent, nicht nur während der Fehlerflut beim Start.

Der entscheidende Punkt ist der direkte Vergleich:

  • v4.70.0 → 60% CPU konstant, gleiche Fehler beim Start

  • v4.66.8 → 4% CPU konstant, gleiche Fehler beim Start (Timing-Problem existiert in beiden Versionen)

Also hat sich zwischen v4.66.8 und v4.70.0 etwas geändert, das eine CPU-Verschlechterung verursacht, zumindest in meiner Konfiguration mit MQTT. Die Fehler beim Start sind ein separates (älteres) Problem.

6

@bamboleate Vielen Dank für den Bericht und Entschuldigung für die Unannehmlichkeiten.

Hast du zwischenzeitlich andere Gladys-Versionen installiert?

Hier ist das vollständige Changelog:

Könntest du bitte Version für Version aktualisieren, bis du herausfindest, welche Version das Problem verursacht?

Das würde uns helfen, genau zu bestimmen, welche Version das Problem verursacht hat, was die Untersuchung für uns viel einfacher machen würde.

7

Mein erster Instinkt sagt, dass es von 4.70 stammt, weil ich vorher Watchtower aktiviert hatte und mich nicht mit dem Micromanagement aller Versionen beschäftigt habe. Als ich jedoch erstmals mit dem Problem konfrontiert wurde, war es 4.70, und ich habe nur etwas heruntergestuft, um nicht so viel herumzufummeln und es einfach wieder zum Laufen zu bringen.

ABER ich werde alle Versionen irgendwann installieren, um Ihnen bei der Eingrenzung des Problems zu helfen. Natürlich bin ich dieses Wochenende nicht verfügbar, also wird es etwas dauern.. Ich melde mich, wenn ich mehr weiß
DANKE für alles, was Sie tun und getan haben!

8

Hi @pierre-gilles,

Ich habe das schrittweise Upgrade so durchgeführt, wie du es vorgeschlagen hast. Hier sind meine Ergebnisse:

  • v4.66.9 → CPU normal, keine Probleme
  • v4.67.0 → CPU springt sofort auf ~57% und bleibt dort

Das Problem wurde also in v4.67.0 eingeführt.

Der Changelog dieser Version zeigt nur drei Änderungen:

  • Nuki-Integration
  • Gladys Gateway DuckDB-Backup bei temporärer DB-Verbindung
  • Upgrade der HAP-Abhängigkeit auf die neueste stabile Version

Ich nutze HomeKit/Apple Home nicht, daher kann ich nicht bestätigen, ob das HAP-Update der Übeltäter ist — aber es scheint der wahrscheinlichste Kandidat für eine CPU-Schleife zu sein.

Hoffentlich hilft das, es einzugrenzen!

9

Siehst du genau, welcher Prozess den CPU-Spike verursacht? Ist es der Gladys node.js-Prozess?

Nichts Seltsames in den Logs?

10

Hi @pierre-gilles,

Die Logs zeigen etwas Interessantes. Es gibt eine Flut von unbehandelten Promise-Ablehnungen im Zusammenhang mit nicht gefundenen MQTT DeviceFeatures:

NotFoundError: DeviceFeature mqtt:wozipi:07 not found
NotFoundError: DeviceFeature mqtt:wozipi:10 not found
NotFoundError: DeviceFeature mqtt:wozipi_bme680:temperature not found
[...und so weiter]

Diese Fehler treten alle paar Sekunden auf (mein WoZiPi sendet MQTT-Nachrichten kontinuierlich). In v4.66.9 wurde dies offenbar stillschweigend behandelt — in v4.67.0 scheint es eine CPU-Schleife zu verursachen.

Auch bemerkenswert: ps aux ist nicht im Container verfügbar, aber die Fehler stammen alle vom Node.js-Prozess (index.js), also ja — es ist der Gladys Node.js-Prozess, der den Anstieg verursacht.

Ich verwende kein HomeKit, daher ist das HAP-Abhängigkeits-Update wahrscheinlich nicht der Übeltäter. Meine Vermutung wäre eine Änderung in der Behandlung unbehandelter Promise-Ablehnungen zwischen v4.66.9 und v4.67.0.

Hoffe, das hilft!

11

Seltsam, denn an diesem Teil wurde nichts geändert!

Ich frage mich, ob das von der Nuki-Integration kommen könnte, weil die Nuki-Integration MQTT verwendet, um MQTT-Nachrichten von Nuki-Schlössern zu empfangen.

Cc @ProtZ

12

Übrigens, wir werden in der nächsten Gladys-Version eine Verbesserung für die Nuki-Integration veröffentlichen, um zu verhindern, dass die Nuki-Integration gestartet wird, wenn sie nicht konfiguriert ist. Das könnte dir definitiv dabei helfen!

(bin mir nicht 100% sicher)

13

Hmm.. das ist mir alles zu hoch. Falls ich etwas beitragen kann, das dir hilft, melde dich einfach.

14

Ich werde sehr bald die neue Gladys-Version mit diesem Fix veröffentlichen und würde dich bitten, die Version zu testen, um zu sehen, ob sie dein Problem behebt.

Falls nicht, werden wir gemeinsam weiter untersuchen :blush:

15

Ich bestätige diesen Punkt, ich habe ebenfalls Nuki-Logs, die vorher nicht vorhanden waren und mit MQTT zusammenhängen.

Bisher wird die Last auf meiner Seite vom Mini-PC noch toleriert, aber das hat mich neugierig gemacht. Ich hatte noch keine Zeit, dies zu untersuchen.

16

Hallo,
Ich bestätige, dass die überflüssigen MQTT-Logs von der Nuki v1-Integration stammen. Das wurde normalerweise in der Version 1.0.1 behoben (mutmut hatte dieses Problem bereits bei der G4.67-Release entdeckt). Das MQTT-Abonnement beim Start erfolgte für alle vorhandenen Geräte, das Suchattribut war falsch konfiguriert und ging über den Nuki-Dienst hinaus. Das sollte jedoch keine größeren Auswirkungen haben.

17

@bamboleate Ich habe gerade ein Gladys-Update (v4.71.0) mit dem Fix veröffentlicht, lass mich wissen, ob es dein Problem löst!

18

Hallo @Pierre-Gilles,

Ich habe von v4.66.8 auf v4.71.0 aktualisiert und sehe immer noch eine CPU-Auslastung von ~60–70%. Nach einigen tiefen Debugging-Sitzungen habe ich zwei separate Probleme gefunden:

Problem 1: Race Condition mit MQTT-Retained-Nachrichten (Startup-Crash-Loop)

Beim Start spielt Mosquitto sofort alle gespeicherten Nachrichten auf gladys/master/# ab, bevor Gladys seinen Geräte-Cache vollständig geladen hat. Dies führt zu einer Flut von NotFoundError: DeviceFeature mqtt:xxx not found-Fehlern — einen pro gespeichertem Thema, pro Neustart. Der CPU-Spike wird durch die ungehandeiten Promise-Ablehnungen verursacht, die die Event-Loop überlasten.

Workaround: Löschen aller gespeicherten Nachrichten auf gladys/master/# mit mosquitto_pub -r -n. Nach einem Neustart füllt Gladys sie wieder auf und funktioniert korrekt — aber nur bis zum nächsten Neustart.

Das scheint ein Bug zu sein, bei dem der MQTT-Dienst sich abonniert, bevor der Geräte-Manager die Initialisierung abgeschlossen hat.

Problem 2: LAN Manager Presence Scanner ruft ip neigh show in einer engen Schleife auf

Selbst wenn der LAN Manager in der UI auf « deaktiviert » gesetzt ist (und LANMANAGER_PRESENCE_STATUS=disabled in der DB bestätigt wurde), führt Gladys weiterhin ip neigh show über execve kontinuierlich aus. Da ip nicht in dem Gladys Docker-Image installiert ist (Exit-Code 127), scheitert jeder Aufruf sofort und die Schleife wiederholt sich.

Ich habe dies mit strace -f -e execve auf der Gladys-PID bestätigt.

Workaround: Das Injizieren eines Dummy-ip-Skripts, das sauber beendet, reduziert den Overhead leicht, aber die Schleife selbst läuft weiter.

Dies scheint ein Bug zu sein, bei dem der LAN Manager den deaktivierten Zustand zur Laufzeit nicht respektiert.

Umgebung:

  • Gladys v4.71.0 (aktualisiert von v4.66.9)
  • Docker, network_mode: host
  • Externer Mosquitto-Broker (eclipse-mosquitto:2.0)
  • ~30 MQTT-Geräte (auf mehreren Pis)
  • Host: Ubuntu 24.04, 32 GB RAM

Ich bin gerne bereit, weitere Logs bereitzustellen oder Patches zu testen, falls hilfreich. Danke!

19

Danke für das Feedback, ich werde mich um beide Probleme kümmern :+1:

Dabei glaube ich nicht, dass sie in Gladys v4.67.0 eingeführt wurden, also sind sie wahrscheinlich nicht die Ursache für den hohen CPU-Verbrauch, den du siehst.

Da du erwähnt hast, dass der CPU-Verbrauch konstant ist (nicht nur beim Start), sieht es auch nicht nach einem Problem mit behaltenen Nachrichten aus.

Du hast auch gesagt, dass dein WoZiPi kontinuierlich MQTT-Nachrichten sendet, hast du eine Idee von der Nachrichtenrate (z. B. Nachrichten pro Sekunde)?

Eine mögliche Erklärung ist, dass es kein eigentliches „Bug“ gibt, sondern eher eine Durchsatzbegrenzung:

Mit dem zusätzlichen Code, den wir kürzlich hinzugefügt haben (insbesondere rund um Nuki), könnte die MQTT-Integration etwas langsamer bei der Verarbeitung von Nachrichten sein. Wenn deine Einrichtung Nachrichten in hoher Frequenz sendet, könnte Gladys nicht mithalten, was zu einem Rückstau und erhöhtem CPU-Verbrauch führt.

Falls das der Fall ist, wäre die Lösung wahrscheinlich, die MQTT-Verarbeitung in Gladys zu optimieren, um den Durchsatz zu verbessern.

Lass mich wissen, wie hoch das Nachrichtenaufkommen ist, das würde helfen, es einzugrenzen!

20

Hi @Pierre-Gilles,

Ich habe die MQTT-Nachrichtenrate mit mosquitto_sub -t '#' gemessen, durch pv gepipet:

~0.8 Nachrichten/Sekunde (291 Nachrichten über ~6 Minuten, alle Themen kombiniert)

Das scheint eher niedrig zu sein, daher denke ich nicht, dass die Durchsatzrate das Problem ist. Die hohe CPU-Auslastung (~60–70%) ist konstant und korreliert nicht mit Nachrichten-Spitzen.

Zum Vergleich: Meine Einrichtung veröffentlicht Relais-Zustände von drei Raspberry Pis (WoZiPi und AZiPi, SchlaZiPi) sowie BME680- und SHT35-Sensordaten — nichts besonders „redseliges“.