FHEM wird immer langsamer nach ein paar Stunden.

Begonnen von Basti-K, 14 Mai 2022, 10:55:19

Vorheriges Thema - Nächstes Thema

Basti-K

Hallo Zusammen.
Meine FHEM Installation hat seit einer Woche ein Problem.
Nach ein paar Stunden Betrieb  (Neustatet des FHEM Diensts, oder des Servers) wird wird fhem immer langsamer von den Reaktionen. (Webseite, oder auch die mqtt Verbindungen bekommen timeouts) nach 18h geht gar nix mehr. Dann hat der perl Prozess 100%
Normal wären eigentlich um die 50%
Der Server (Raspi 3) läuft in dem zustand trotzdem ohne Problem weiter.
Auf dem Ding läuft noch:
Evcc
Pihole
Docker: Jdownloader und vaultwarden
die 4 Dienste haben überhaupt kein Performance Problem.
Apt ugrade durchgeführt (in der Hoffnung dass das hilft. Nö)

Als Gegentest wurden sie auch mal deaktiert. Fhem alleine verursacht das Problem

Es wurden keine Änderungen an der config vorgenommen. Die letzte kleine Änderung liegt Monate zurück. (Irgendwann gibt es nix mehr zu tunen)

Fhem > Update all durchgeführt aber ändert nichts.

Erwähnenswerte Module:
mqtt
Signalbot
CUL Stick (für HM und 433 Mhr Drücker)
Go-echarger (eigentlich überflüssig, weil die Laderegelung über evcc läuft, aber man(n) will hat alle Daten zentral haben)
E3DC also Modbus
Google Assistent
Ich hab mal alle Log gelöscht und ein tail auf das FHEM log laufen.
Da ist kein Fehler zu sehen.
Das alte log wurde mit grep nach error oder fehler durchsucht. Nichts...
Bei alles Geräten wurde event-on-change-reading   .* gesetz.
Funktionieren tut auch alles grundsätzlich alles.... für ein paar Stunden.
Nun bin ich etwas ratlos hat noch jemand eine Idee?

JensS

Es gibt ein schönes Modul namens Freezemon. Damit kannst den Verursacher eventuell eingrenzen.
defmod Freeze freezemon
attr Freeze fm_freezeThreshold 3
attr Freeze verbose 3


Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Beta-User

Hmm, meine Glaskugel meint, dass da ein paar forkende Prozesse zusammenfallen, die dann dazu führen, dass der Speicher nicht reicht => swap => ausgebremst.... Das System fängt sich manchmal wieder, aber irgendwann kommt ein weiterer fork dazu => aus die Maus...?

Hast du zufällig PRESENCE in Ping im Einsatz? Dann schau mal nach der Variante von martinp876!

Weitere Anmerkungen:
- 50% als "Normalzustand" ist jedenfalls nach meinem Empfinden nicht akzeptabel
- "event-on ... .*" ist ein Anfang, aber kein Allheilmittel! Bau v.a. bei Sensoren Hysteresen ein!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Basti-K

@Beta-User
PRESENCE hab ich nicht. Aber mir ist aufgefallen das google das sein "Home" total umgeworfen hat. das würde auch in etwas so in die Richtung gehen.
nicht das der gAssistent der Übeltäter ist.

den Frostwarner will ich mal ausprobieren.

Hysterese kenne ich nur in einen andern Kontext.
aber ich hab auch da gegoogelt...
ich hab ein paar wait  im Einsatz.
wieso werden die auf einmal zum Problem?
oder meinst du etwas anderes?

Beta-User

#4
Zitat von: Basti-K am 14 Mai 2022, 21:27:25
Hysterese kenne ich nur in einen andern Kontext.
[...]
oder meinst du etwas anderes?
Such' mal in https://fhem.de/commandref_modular_DE.html nach readingFnAttribute bzw. der Beschreibung zu event-on-change-reading

Generell kannst du ja mal schauen, was bei dir so alles durch den Event-Monitor rauscht.

Man kann das Attribut übrigens auch als "Positiv-Liste" füllen - dann gibt "der ganze Rest" gar kein Event (wenn man es nicht an anderer Stelle (...on-update) aktiviert).

Ansonsten war PRESENCE nur ein "prominentes Beispiel", das häufig im Zusammenhang mit Problemen beim Forken auftaucht. Kann auch alles mögliche andere sein.
Hast du Aufzeichnungen zur Speichernutzung? (Es gibt zum Thema Speicherloch (=eigentlich ein anderes Thema) auch einen gesonderten Thread, da stehen auch einige Hinweise drin, die dir ggf. weiterhelfen könnten).

Nachtrag:
Hier mal mein archetype, das für das Setzen der readingFnAttributes für CUL_HM-Thermostat-Devices zuständig ist. Vielleicht probierst du das mal aus, falls du sowas hast...

defmod archHM_RT_DN archetype TYPE=CUL_HM:FILTER=model=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU)
attr archHM_RT_DN userattr actual_devStateIcon_4 actual_devStateIcon_WT actual_event-min-interval_0 actual_event-min-interval_4 actual_event-min-interval_WT actual_event-on-change-reading_0 actual_event-on-change-reading_1 actual_event-on-change-reading_4 actual_event-on-change-reading_WT actual_group actual_icon actual_icon_1 actual_icon_2 actual_room actual_room_4 actual_room_WT actual_tempListTmpl actual_tempListTmpl_4 actual_userattr_4 actual_webCmd_4 actual_widgetOverride_4 actual_widgetOverride_WT
attr archHM_RT_DN actual_devStateIcon_4 model=HM-CC-RT-DN:FILTER=chanNo=04 Perl:{devStateIcon_Clima($name)}
attr archHM_RT_DN actual_devStateIcon_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 Perl:{devStateIcon_Clima($name)}
attr archHM_RT_DN actual_event-min-interval_0 DEF=.{6} measured-temp:900,desired-temp:1800,humidity:1800,actuator:7200
attr archHM_RT_DN actual_event-min-interval_4 model=HM-CC-RT-DN:FILTER=chanNo=04 measured-temp:900,desired-temp:1800
attr archHM_RT_DN actual_event-min-interval_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 measured-temp:900,desired-temp:1800,humidity:1800
attr archHM_RT_DN actual_event-on-change-reading_0 DEF=.{6} measured-temp:0.2,.*,
attr archHM_RT_DN actual_event-on-change-reading_1 model=HM-CC-RT-DN:FILTER=chanNo=01 none
attr archHM_RT_DN actual_event-on-change-reading_4 model=HM-CC-RT-DN:FILTER=chanNo=04 measured-temp:0.2,.*
attr archHM_RT_DN actual_event-on-change-reading_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 measured-temp:0.2,.*
attr archHM_RT_DN actual_group Heizung
attr archHM_RT_DN actual_icon_1 model=HM-CC-RT-DN hm-cc-rt-dn
attr archHM_RT_DN actual_icon_2 model=HM-TC-IT-WM-W-EU hm-tc-it-wm-w-eu
attr archHM_RT_DN actual_room Steuerung->Heizung
attr archHM_RT_DN actual_room_4 model=HM-CC-RT-DN:FILTER=chanNo=04 undef:Steuerung->Heizung
attr archHM_RT_DN actual_room_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 undef:Steuerung->Heizung
attr archHM_RT_DN actual_tempListTmpl_4 model=HM-CC-RT-DN:FILTER=chanNo=04 none
attr archHM_RT_DN actual_userattr_4 model=HM-CC-RT-DN:FILTER=chanNo=04 weekprofile
attr archHM_RT_DN actual_webCmd_4 model=HM-CC-RT-DN:FILTER=chanNo=04 desired-temp
attr archHM_RT_DN actual_widgetOverride_4 model=HM-CC-RT-DN:FILTER=chanNo=04 desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
attr archHM_RT_DN actual_widgetOverride_WT model=HM-TC-IT-WM-W-EU:FILTER=chanNo=02 desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
attr archHM_RT_DN attributes room webCmd tempListTmpl group widgetOverride event-min-interval event-on-change-reading
attr archHM_RT_DN room Steuerung->Config


Und hier das für einen per OpenMQTTGateway eingefangenen Temperatursensor:
defmod archOMGTemp archetype TYPE=MQTT2_DEVICE:FILTER=a:model=OpenMQTTGateway_BT_temp_hum_sensor
attr archOMGTemp userattr actual_event-min-interval actual_event-on-change-reading
attr archOMGTemp actual_event-min-interval batteryPercent:7200,temperature:300,humidity:900
attr archOMGTemp actual_event-on-change-reading batteryPercent,temperature:0.2,humidity:0.5,distance:5
attr archOMGTemp attributes event-on-change-reading event-min-interval
attr archOMGTemp room Steuerung->Config
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Basti-K

Das werde ich mir morgen in Ruhe anschauen (aktuell ist das Wetter zu gut)
Ja HM Thermostate hab ich einige Einsatz...
Gestern Abend habe ich mich noch mit dem Freeze Monitor beschäftigt er hat was gefunden.
Die Modbus Verbindung zur PV Anlage scheint der Übeltäter zu sein.

Da war noch das Update Intervall sehr niedrig (stammt noch aus der Zeit wo ich das Überschuss Laden mit fhem gesteuert hab)
Es stand auf 5 Sekunden was alleine für 30% last verantwortlich ist bzw. war.
Ich habe das jetzt mal auf 60 Sekunden gestellt.
Ich benötige die Infos in fhem noch für meine Statistiken und weil ich die String Leistung als licht Sensor missbrauche für die Rollladen Steuerung.
Nach 14h ist die Prozesslast von anfänglich ~20 auf 70% gestiegen. Fhem läuft nun zäh aber ist noch bedienbar.
Der Frost Wächter schimpft aber immer noch über das Modul und seit dem ich die Zeit auf 60 gestellt hab ist nun auch ein CUL Device dabei.

Wernieman

Und wie sieht der Speicher des Pis aus?

Also:
free
ps aux | grep perl


Wenn Du für das letzte Kommando eine Erklärung möchtest, kannst Du auch:
ps aux | head -n1 ; ps aux | grep perl
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

JensS

Einfach mal ins Blaue geschossen - gibt's ein Bosch Indego in der Installation?
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Basti-K

pi@FHEM:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         996096      473972       68816       18784      453308      447568
Swap:             0           0           0
pi@FHEM:~ $ ps aux | grep perl
fhem       880 52.4 13.8 148652 137980 ?       S    Mai15 697:01 perl fhem.pl fhem.cfg
fhem      1979  0.6 13.3 148652 133144 ?       S    17:58   0:00 perl fhem.pl fhem.cfg
pi        1981  0.0  0.0   7360   568 pts/0    S+   17:58   0:00 grep --color=auto perl
pi@FHEM:~ $


was ist den Mail?

Wernieman

50% Memory belegt ...... und 52% CPU Leistung ist auch nicht wenig ...

hast Du den SWAP ausgeschaltet?

Woher Du zum Wort "Mail" kommst ....... ist mir ein Rätsel

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

JensS

#10
Seit dem 15. Mai läuft der Prozess - also keine 5 Mails.  ;)

Bei meiner Installation (nur mal zum Vergleich) sieht es momentan so aus:
fhem     12658  3.1  5.5 242804 224652 ?       S    Mai13 144:37 /usr/bin/perl fhem.pl fhem.cfg
fhem     12709  0.0  3.3 157508 135608 ?       S    Mai13   0:00 /usr/bin/perl fhem.pl fhem.cfg


Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Wernieman

Es lohnt sich nicht, meine Werte hier reinzupusten, da es eine größere Plattform (Also der Server, nicht FHEM)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Beta-User

Auch wenn es schwierig ist, "free" etc. richtig einzuschätzen, bisher ungenutzt waren bei diesem "snapshot" lediglich knapp 70k. Das ist weniger wie ein FHEM-Prozess (der mit ~130k eher "klein" bis "normal" aussieht) => ein fork _kann_ also zu swap-Nutzung führen.

Es kann durchaus auch sein, dass die "anderen Kleinigkeiten", die noch auf dem Ding laufen dann halt Daten im Memory cachen und der deswegen nach und nach vollläuft.

Was man aber _auch_ sieht: im Zeitpunkt des snapshots gab es einen fork. An sich nicht schlimm, aber ggf. wäre die Frage, ob sich das reduzieren läßt, z.B. bei DbLog durch entsprechende Pufferungen usw.. Dazu müßte man aber mehr wissen, als wir hier vorgesetzt bekommen haben.

Und auch die Frage nach der Häufigkeit von Event allgemein wurde - soweit erkennbar - noch nicht wirklich beantwortet.

Ggf. kannst du mal das neue Tool von Rudi ausprobieren, damit bekommt man auch einen gewissen Eindruck von dem, was abgeht:
https://forum.fhem.de/index.php/topic,127077.msg1221501.html#msg1221501

Müßte in etwa so funktionieren:
Das Tool nach contrib runterladen, ausführbar machen.

Einige Zeit (2 Minuten für den Einstieg?) FHEM mit globalem verbose 5 laufen lassen, danach wieder zurückstellen.
Auf der Linux-Kommandozeile ins Log-Verzeichnis (/opt/fhem/log) wechseln, dort
sudo -u fhem perl ../contrib/sumUpNotifyTimes.pl fhem-2022-05.log > out.log
und das Passwort eingeben.

Dann out.log ansehen (und/oder wie Rudi visualisieren).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Basti-K

Aktuell fehlt mir etwa die Zeit um das zu bohren, aber ich kann das Thema nicht lange ignorieren, den ich bekomme die Garage nicht mehr via Voice auf...
Den Hinweisen werde ich noch beherzt nach gehen.
Also Hinweis hätte ich noch, wenn ich fhem stop erholt sich der Speicher. Starte ich neu hat man auch erst mal ein eine Zeit Ruhe. QnD Lösung wäre ein Chron Job der das macht, aber sauber ist das natürlich nicht.
Soll ich mal meine conf posten? Aber die ist sehr lang.

Beta-User

Zitat von: Basti-K am 17 Mai 2022, 18:25:02
Soll ich mal meine conf posten?
M.E.: Nein. Das ist dein Job, zumindest mal die Basics zu klären, ggf. den Speicherverbrauch zu loggen und eine Kurzfassung (!) dessen zu liefern, was eigentlich "Sache" ist (fheminfo ist zwar in Teilen kaputt, (z.B. was CUL_HM angeht) aber das wäre z.B. eine erste Orientierung). Eine "out.log" schaue ich mir aber gerne an ;) .

Aber das ist meine Meinung zum Thema, kann sein, dass andere das anders sehen....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files