Sporadisch lange Antwortzeiten FHEMWEB

[FhemPiUser]

Hi,

ich messe automatisiert alle 5min die Antwortzeit von FHEMWEB von meinem NAS aus mit einem "curl -w" und stelle (auch bei manueller Bedienung) fest, dass ab und an (ca. 1-2x pro Stunde) FHEMWEB bei mir sehr lange Antwortzeiten von 5s bis zu 15s hat. Auch mit global verbose 4 kann ich aus dem fhem log die Ursache nicht feststellen. Da parallele ping-Messungen vom NAS aus überhaupt keine Verzögerung zeigen, der NAS load i.O. war und andere FHEM devices zum gleichen Zeitpunkt der Verzögerung vom "curl -w" in Logfiles geschrieben haben, scheint auch der NAS, der FHEM Rapsberry 4 (8GB RAM mit SSD) oder FHEM als Prozess insgesamt nicht zu stehen/blockieren. Freezemon hat auch nicht geholfen die Ursache zu finden. Load vom Raspberry ist im Bereich von 0.4-0.5 im Durchschnitt und %CPU fhem sehe ich auch wenn ich mit top schaue nie über 50%. iostat lässt auch nicht auf irgendwelche Probleme mit io schließen...

Hat jemand ähnliche Erfahrungen und eine Idee, was die Ursache sein könnte bzw. wie man diese herausfinden und beheben kann?

[rudolfkoenig]

Die Abarbeitung in FHEM laeuft (bis auf Ausnahmen) nicht parallel (aka es ist "single-threaded").
Wenn irgendeine Aufgabe (notify/DOIF/etc) laenger braucht, dann wartet man auf die FHEMWEB Antwort solange, bis diese Aufgabe erledigt ist.

Um die Ursache zu isolieren wuerde ich in FHEM "attr global verbose 5" aktivieren, bis die Ueberwachung ein Problem meldet, und dann im FHEM-Log die fragliche Zeit untersuchen.

[PatrickR]

Um Langläufer zu identifizieren helfen auch apptime und freezemon.

[FhemPiUser]

danke. Freezemon hatte ich schon probiert.

Mit verbose 5 habe ich eben eine starke Verzögerung (curl Timeout nach 15s um 18:41:47) festgestellt, nachdem der MQTT2_Client die Verbindung zu HiveMQ im Internet kurz verloren hat. Es gab dann auch einen Fehler im Modbus Device.

Code Auswählen Erweitern

2025.08.30 18:38:47.155 4: authorize ...: allowed_WEBwidget_syncclient returned dont care
2025.08.30 18:40:10.519 1: ....s1.eu.hivemq.cloud:8883 disconnected, waiting to reappear (HiveMQ)
2025.08.30 18:40:11.180 1: ... Modbus Error, Message: timeout waiting for reply to fc 4 to id 2

Die Frage, ob MQTT"_Client und Modbus Ursache oder Folge der Verzögerung sind. Falls der MQTT2_Client in Verbindung mit Internetabbrüchen oder ModbusAttr  in Verbindung mit Timeouts tatsächlich die Ursache ist, kann man den MQTT2_Client / ModbusAttr irgendwie so umstellen, dass er nicht fhem blockiert, wenn die Verbindung verliert?

Bei der weiteren Verzögerung war die letzte Zeile vom curl / FHEMWEB:

Code Auswählen Erweitern

2025.08.30 19:10:06.908 4: WEBRegenmesser: /fhem?cmd=get+MeinRegenmesser / RL:5986 / text/html; charset=UTF-8 /  / Cache-Control: no-cache, no-store, must-revalidate
2025.08.30 19:10:10.085 1: SendMessage triggered with Titel: FHEM Raspi checkfhemalivecurltime-Alarm, Message: checkfhemalivecurltime > 5s 5.86s

Kann das "must-revalidate" etwas mit der Verzögerung zu tun haben?

[FhemPiUser]

Die Abarbeitung in FHEM laeuft (bis auf Ausnahmen) nicht parallel (aka es ist "single-threaded").
Wenn irgendeine Aufgabe (notify/DOIF/etc) laenger braucht, dann wartet man auf die FHEMWEB Antwort solange, bis diese Aufgabe erledigt ist.

Um die Ursache zu isolieren wuerde ich in FHEM "attr global verbose 5" aktivieren, bis die Ueberwachung ein Problem meldet, und dann im FHEM-Log die fragliche Zeit untersuchen.

Gibt es irgendweine Möglichkeit für bestimmte zeitkritische devices einen eigenen parallelen Thread zu starten?

Oder eine zweite fhem-Instanz auf dem gleichen Raspberry, die mit der ersten fhem-Instanz kommuniziert?

[rudolfkoenig]

kann man den MQTT2_Client [...] irgendwie so umstellen, dass er nicht fhem blockiert, wenn die Verbindung verliert?

MQTT2_Client duerfte nur dann blockieren, wenn als Ziel ein Rechnername (keine IP Adresse) angegeben wurde, und "attr global dnsServer" _nicht_ gesetzt ist.
Die systemeigene DNS-Bibliothek blockiert gerne 5+ Sekunden, falls der Server nicht antwortet.
Die mit dnsServer aktvierte in FHEM implementierte DNS-Aufloesung sollte blockierungsfrei sein.

Gibt es irgendweine Möglichkeit für bestimmte zeitkritische devices einen eigenen parallelen Thread zu starten?

Das ist mW nur fuer bestimmte Module implementiert (mit BlockingCal, usw), und ist nicht optional.

Oder eine zweite fhem-Instanz auf dem gleichen Raspberry, die mit der ersten fhem-Instanz kommuniziert?

Das ist moeglich, es einzurichten (via FHEM2FHEM, MQTT, etc) bedeutet aber Arbeit.