[gelöst] 100% CPU bei Start von zigbee2mqtt

[87insane]

Hallo zusammen,

ich weiß leider nicht mehr wie ich weiter testen kann und hoffe auf Mithilfe.

Seit ein paar Tagen verhält sich mein FHEM sehr merkwürdig. Nach einigem Suchen, weiß ich nun, dass FHEM komplett normal läuft bis ich zigbee2mqtt starte. Das ist komisch, da mein Zigbee schon sehr lange ohne Thema lief.
Ich habe vor ca. einem Monat von FileLog auf DBLog umgestellt. Das lief auch alles ohne Probleme durch. Ist aber leider die Einzige Änderung die überhaupt gewesen ist.

top sagt:
Nach starten von z2m 100% CPU fhem - perl

Nach viel hin und her testen, ist mir nun aufgefallen, dass wenn ich FHEM im Debug Modus laufen lasse "perl fhem.pl -d fhem.cfg", dann geht alles ohne Thema. Ich kann dann auch ganz normal schalten usw.

Ich brauche nun hier mal einen Rat, wie ich testen kann oder weiter machen kann?
Wenn der FHEM Debug läuft, starte ich diesen ohne sudo oder ähnlichem. Läuft also mit meinem normalem Benutzer und nicht über den FHEM Benutzer. Kann das ggf. einfach ein Berechtigungsthema sein? Ich habe zum testen schon wirklich viel ausgeweitet. 775 war aber das höchste meiner Gefühle.
Zuerst dachte ich das sich ggf. irgendein Event im Kreis dreht (notify/doif). Dem ist leider aber wohl nicht so, sonst müsste dies im Debug Modus ja auch so sein. Oder?

PS: Ich habe auch einfach mal ein Backup zurück gespielt von FHEM. Das hat leider nicht geholfen. Hier sollte ich erwähnen, dass ich meine Backups via Skript auf ein NAS schiebe. Diese werden wöchentlich erstellt und und in ein Archiv gepackt. Hier ist auch der komplette FHEM Ordner drin.

Was braucht Ihr um mir zu sagen, was ich nun tun kann?

Gruß und Danke für jede Hilfe!


Zusatz Infos:
Pi4 8GB
SSD
Direkt via Rj45 verbunden
DBLog via Maria/MySQL

z2m Version geupdatet ohne Erfolg (Aktuell auf 1.42.0)
Im FHEM Log ist nichts zu finden was hilft. Sieht aus wie ein normaler Start.

Hier habe ich natürlich auch geschaut:
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche

[TomLee]

Moin,

steht vlt. was dazu im z2m-Log (normal: cd/opt/zigbee2mqtt/data/log/...)?
Wird der Stick erkannt?

[Otto123]

alles auf einer Maschine? initial Usb Check von FHEM aktiv -> deaktivieren?

Code Auswählen Erweitern

attr initialUsbCheck disable

[87insane]

Moin,

steht vlt. was dazu im z2m-Log (normal: cd/opt/zigbee2mqtt/data/log/...)?
Wird der Stick erkannt?

Der Stick wird erkannt. Wie gesagt ist FHEM im Debug Modus ganz normal und funktioniert. Im LOG von z2m steht leider auch nichts.

alles auf einer Maschine? initial Usb Check von FHEM aktiv -> deaktivieren?

Ja, alles auf dem einen PI. Das geht auch sehr gut, wenn man die Events in FHEM ein wenig eingrenzt. Da läuft z.B. auch noch Grafana drauf.
Das attr ist disable. Mache ich bei jeder FHEM Installation.


Gibt es bis auf die eine Seite, die ich oben mit angehnagen habe, keine weiteren Test/Debug Wege für FHEM?

[Otto123]

Naja, nur mal laut gedacht:
Was ist anders wenn FHEM im Debug Modus läuft? Er schreibt nicht ins fhem Log (jetzt Datenbank?) sondern in die Standardausgabe.
Was passiert wenn Du Z2M startest? die MQTT Devices senden Erfahrungsgemäß ziemlich viel, d.h. der MQTT2 Server von FHEM muss arbeiten.

Klingt irgendwie, als ob der Prozess von MQTT -> FHEM -> Datenbank klemmt/überlastet. Beißt sich da was zwischen der Z2M Installation und FHEM mit Datenbank?

Man könnte die Events im MQTT2 Server beobachten - mit und ohne debug Modus.

Gefühlt würde ich das Thema nicht im Anfängermodus belassen, sondern nach MQTT verschieben.

Gruß Otto

[87insane]

Guter Ansatz!

Ich habe zwei z2m Instanzen. In der einen sind nur 3 Geräte. Diese kann ich mit hoch fahren und es geht.
In der zweiten Instanz sind ca. 40 Geräte. Die Meisten sind Lampen. Also dauer bestromt und senden dementsprechend einiges.

Nur das ganze lief ja auch seit ca. 4 Wochen. Daher macht mich das stutzig. Kann ich irgendwo sehen, was genau die DB macht? Ich sehe leider nur den FHEM-perl Prozess der auf 100% springt. Wenn man z.B. die z2m Instanz wieder stoppt, bleibt der Prozess weiterhin auf 100%.
Mit deiner Logik würde ich als erstes mal die DB ausschalten um zu sehen ob es damit zusammen hängt.
Innerhalb des Debug Modus kann ich zwar sehen das FHEM Dinge macht aber es ist unmöglich zu sehen was genau. Da passiert einfach zu viel.

Die DB lasse ich auch nur auf folgende Events laufen:
./db.conf .*:(t_humidity|t_temperature|s_state|occupancy|illuminance_lux|presence|Brenner_1_Modulation|HK1-Vorlauftemperatur|HK2-Vorlauftemperatur|WW-Isttemperatur|Aussentemperatur|relay_0_power|relay_0_kWh_total|kWh_kosten|apower|aenergy_total_kwh|c_own_state|desired-temp|loadState).*

[Otto123]

Läuft denn das normale fhem log auch in die DB? Mein Gedanke war ja: da ist der Unterschied zwischen Debug und normal Modus.

Wenn der zweite Z2M Prozess das Problem triggert und es danach aktiv bleibt - dann kämpfen dort eventuell zwei Prozesse um die gleichen Ressourcen? Was ist wenn Du FHEM nach dem Z2M Prozess startest?

Ich habe leider keine konkrete Idee.

[rippi46]

Hallo

hatte ein ähnliches Problem als von FileLog auf DB umgestellt hatte.

Habe alle Änderungen immer direkt in die DB geschrieben, dadurch wurde mein fhem stark blockiert.

Nachdem ich dann in der   "/etc/mysql/my.cnf"   (könnte auch wo anders liegen) den Eintrag "innodb_flush_log_at_trx_commit = 2" eingefügt hatte lief alles wieder normal.


Gruß rippi

[87insane]

Das FHEM.log ist weiterhin FileLog. Nur die Geräte Logs habe ich in die DB geschoben.

Ich habe nun mal alles mögliche in Richtung, wer startet zuerst probiert.
Der "kleinere" z2m macht nie Probleme. Der "größere" sorgt jedes mal dafür. Das war früher nicht so.

Ich habe in FHEM dblog disabled. Das scheint aber nicht zu reichen. Zudem habe ich das pm2 start skript deaktiviert (welches z2m startet).
z2m Kann nicht gestartet werden, wenn der mqtt Server nicht vorhanden ist.

Ich würde gerne in den einen Prozess der auf 100% geht, hineinschauen oder mehr über ihn erfahren. Hast du da ne Idee?


@rippi46:
Habe ich gerade Testweise mal in der /etc/alternatives/my.cnf gesetzt aber ohne Erfolg. Gleiches Verhalten :\
Ich tappe ein wenig im dunklen, da es ja alles mögliche sein kann. Ich kann nicht sagen woran es liegt. DB war ne gute Idee von Otto123. Aber wenn ich diese in FHEM disable, sollte das ja kein Thema mehr sein.


Was man sieht beim starten von z2m ist das sobald er gegen den MQTT Server verbunden ist, passiert das mit den 100% CPU. Auf Consolen Ebene kann ich alles noch ganz normal machen aber alles gegen z2m oder FHEM ist in dem Moment erstmal nicht möglich.

Noch ein Hinweis: Ich habe alle Geräte aus dieser z2m Instanz gelöscht (yaml Datei). Selbst dann geht perl auf 100%.

[RalfRog]

Prozess von MQTT -> FHEM -> Datenbank klemmt/überlastet

Wenn die DB überlastet ist müsste sich das nicht durch seeehr viele Einträge in kurzer Zeit in der Datenbank bemerkbar machen.

Ich habe in FHEM dblog disabled

./db.conf .*:(t_humidity|t_temperature|s_state|occupancy|illuminance_lux|presence|Brenner_1_Modulation|HK1-Vorlauftemperatur|HK2-Vorlauftemperatur|WW-Isttemperatur|Aussentemperatur|relay_0_power|relay_0_kWh_total|kWh_kosten|apower|aenergy_total_kwh|c_own_state|desired-temp|loadState).*

Wäre es nicht geschickteer statt "disable" einfach die DEF massiv abzuspecken. Ggfs. einfach ein einzelnes Gerät:Reading:.* statt .*:... nehmen.

Es gibt ja auch noch das Attribut "asyncMode" für DBLog, um durch das Modul zunächst Daten zu puffern statt sofort zu schreiben.


...falls DBLog das Problem ist.


Gruß Ralf

[87insane]

asyncMode ist an, seit beginn der DB. Hatte das irgendwo gelesen, dass es Sinn macht wegen Blocking.
Wenn ich die DB disable sollte es doch den gleichen Effekt haben. Daher erstmal die Kanone für den Spatz. Mir ist nach wie vor nicht klar ob es wirklich daher kommt.

[passibe]

Ich habe alle Geräte aus dieser z2m Instanz gelöscht (yaml Datei). Selbst dann geht perl auf 100%.

Moment, also du hast jetzt alles in dieser z2m-Instanz gelöscht und die CPU-Last geht trotzdem hoch? Also obwohl da keine Zigbee-Devices mehr sind?

Kannst du mal mit MQTT-Explorer o.ä. loggen, was z2m denn (beim Start, aber nicht nur) für MQTT-Nachrichten an FHEM schickt? Das ist ja die einzige Stelle, wo z2m mit FHEM interagiert.

[Otto123]

Kannst du mal mit MQTT-Explorer o.ä. loggen,

Das geht doch auch mit MQTT2 Server ?

[passibe]

Hab das FHEM-interne logging noch nie gebraucht/benutzt, deshalb auch "o.ä." aber gut, dass du darauf hinweist!

[Otto123]

Ich wollte übrigens überhaupt nicht sagen: die DB ist Schuld. Ich hab nur die Unterschiede aufgezählt.

Mit allen Zusatzantworten erhärtet sich mein Verdacht: es hat wahrscheinlich nichts mit Datenaufkommen zu tun, es sei denn es wird eine Schleife getriggert. Ich vermute immer auch noch: Z2M greift auf etwas zu und FHEM kämpft anschließend dagegen an. Welche Schnittstelle verwendet den die zweite Z2M Instanz? Oder welche Ports öffnet die zweite Z2M Instanz?