FHEM knabbert ständig mehr vom RAM weg

Begonnen von FlatTV, 10 April 2025, 05:48:00

Vorheriges Thema - Nächstes Thema

FlatTV

Hallo zusammen,
ständig wird der RAM im PI4 immer knapper, je länger FHEM läuft.
Ein shutdown restart behebt das Problem wieder.

Die Beiträge zu diesem Thema sind alle schon älter, bevor ich jetzt einfach einen Trigger zum Neustart setze, hat da noch jemand eine Idee?

Im Anhang sieht man den Verlauf nach einem Neustart sehr schön.
Im Log findet sich erstmal nichts auffälliges, was an anderen Tagen nicht auch passiert.
Raspi3 - im wesentlichen mit Phoscon, HomeMatic ( aktuell über debmatic), CUL, BOSE-ST und Alexa (Connector)

rudolfkoenig

ZitatDie Beiträge zu diesem Thema sind alle schon älter, bevor ich jetzt einfach einen Trigger zum Neustart setze, hat da noch jemand eine Idee?
Ich kenne leider keine neue Methode, nur die schrittweise Abschaltung einzelner Module.
Ist mAn nur dann praktikabel, wenn der Speicherverlust schnell feststellbar ist.

cnkru

Zitat von: FlatTV am 10 April 2025, 05:48:00Hallo zusammen,
ständig wird der RAM im PI4 immer knapper, je länger FHEM läuft.
Ein shutdown restart behebt das Problem wieder.

Die Beiträge zu diesem Thema sind alle schon älter, bevor ich jetzt einfach einen Trigger zum Neustart setze, hat da noch jemand eine Idee?

Ist bei mir auch der Fall ...
Hatte mehrere Abstürze wegen RAM- Überlauf ...

Habe mich sehr lange mit der Fehlersuche beschäftigt - fhem abgespeckt, dann die fhem.cfg in 20 cfg-Dateien systematisch umgebaut.
Habe leider keinen Übeltäter gefunden. Der RAM läuft weiterhin jede Woche systematisch voll.

Nutze jetzt SYSMON und ein At zur Überprüfung RAM-Ausnutzung und habe vorsichtshalber jeden Sonntag einen Neustart eingebaut



defmod sysmon SYSMON 360 60 360 3600
attr sysmon alias sysmon
attr sysmon disable 0
attr sysmon event-on-update-reading swap,cpu_temp,cpu_temp_avg,cpu_freq,eth0_diff,loadavg,ram,fs_.*,stat_cpu_percent
attr sysmon filesystems fs_boot:/boot/firmware,fs_root:/:Root
attr sysmon group RPi
attr sysmon network-interfaces eth0:eth0:Ethernet,wlan0:wlan0:WiFi
attr sysmon room System
attr sysmon stateFormat RAM Prozent %

##########
und das at ...
##########

defmod at_RamTest at +*01:10:00 { my $wert = ReadingsVal("sysmon","ram",0);
my $end = index($wert,"\%");
my $proz = substr($wert,$end-6,2);
fhem("setreading sysmon Prozent $proz");
$wert = int ReadingsNum("sysmon","Prozent",0);
if ($wert > 80) {
print "Alarm_RAM_Voll_1: RAM-Auslastung beträgt ".$wert." Restart FHEM!!\n";;
DebianMail("user\@gmx.de","FHEM-Alarm Hauptspeicher","Achtung Hauptspeicherauslastung beträgt ".$wert."!");
{system('sudo /opt/fhem/fhem_restart.sh&');}
   }
}


#########
oder alternativ ein Restart jeden Sonntag nutzen
#########


defmod atRestart at *08:00:00 {\
if ($wday == 0) {\
print "Restart FHEM: Pflege RAM-Freigabe\n";;\
{fhem("save");;}\
{system('sudo /opt/fhem/fhem_restart.sh&');;}\
}\
}
attr atRestart alias Restart_FHEM


in de restart.sh steht nur "/bin/systemctl restart fhem "
mit angepassten sudo-Rechten...

Gruß
C.K.

RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

FlatTV

Es ist wieder passiert.
Auffällig sind die gleichzeitig hohen (File)Log Einträge durch eine Device Störung.

Ein Shelly Device verursacht die Log Einträge und schon bläht sich der Speicher auf.

2025.04.12 21:41:53 3: (Shelly_HttpResponse:err) calling Shelly_Set for restarting timer(s) caused by network-error of device Flur_Wechselschalter
2025.04.12 21:41:53 3: [Shelly_Set:startTimer] Flur_Wechselschalter: (Re-)Starting cyclic timers: status-timer=60
2025.04.12 21:42:57 3: (Shelly_HttpResponse:err) calling Shelly_Set for restarting timer(s) caused by network-error of device Flur_Wechselschalter
2025.04.12 21:42:57 3: [Shelly_Set:startTimer] Flur_Wechselschalter: (Re-)Starting cyclic timers: status-timer=60
2025.04.12 21:44:00 3: (Shelly_HttpResponse:err) calling Shelly_Set for restarting timer(s) caused by network-error of device Flur_Wechselschalter
2025.04.12 21:44:00 3: [Shelly_Set:startTimer] Flur_Wechselschalter: (Re-)Starting cyclic timers: status-timer=60
2025.04.12 21:45:03 3: (Shelly_HttpResponse:err) calling Shelly_Set for restarting timer(s) caused by network-error of device Flur_Wechselschalter
2025.04.12 21:45:03 3: [Shelly_Set:startTimer] Flur_Wechselschalter: (Re-)Starting cyclic timers: status-timer=60
2025.04.12 21:46:06 3: (Shelly_HttpResponse:err) calling Shelly_Set for restarting timer(s) caused by network-error of device Flur_Wechselschalter
2025.04.12 21:46:06 3: [Shelly_Set:startTimer] Flur_Wechselschalter: (Re-)Starting cyclic timers: status-timer=60...
Raspi3 - im wesentlichen mit Phoscon, HomeMatic ( aktuell über debmatic), CUL, BOSE-ST und Alexa (Connector)

FlatTV

Ich hab jetzt einen emergency shutdown restart über einen Notify eingestellt.
Prompt habe ich beim Restart von fhem die noch nicht gesicherte Config verloren.

Kann ich irgendwie ein Save Config per Script ausführen?
Ein {fhem("save")} ist wirkungslos.
Raspi3 - im wesentlichen mit Phoscon, HomeMatic ( aktuell über debmatic), CUL, BOSE-ST und Alexa (Connector)

cnkru

Hallo,

vermutlich war das "save" noch nicht durchgeführt ...
Habe nochmal in die restart.sh geschaut - dort wird vor dem Restart noch ein Sleep durhgeführt.
#!/bin/sh
sleep 3
/bin/systemctl restart fhem

Gruß
C.K.

RPi4, Razberry, ZWAVE (Thermostate, Dimmer, Schalter, Multisensor), Milight-LED, Wifi (IPCAM, Fritz!DECT, Sonoff), alexa, Hombridge, Velux-Rollos, Viessman-API, iobroker, SENEC

Markus Stahl

Hallo,

ich stehe momentan auch vor ähnlichen Problemen mit FHEM auf meinem Raspberry Pi. Der RAM läuft ebenfalls relativ schnell voll, vor allem bei längerem Betrieb. Ich habe versucht, ähnliche Lösungen wie ihr umzusetzen, aber der Speicherverbrauch steigt bei mir auch stetig, insbesondere bei den Shelly-Geräten, die ich nutze. Es scheint, dass die Logs tatsächlich den RAM fressen.
Bezüglich des "Save"-Problems: Ich habe auch festgestellt, dass manchmal das "fhem('save')" nicht richtig greift, vor allem wenn der Neustart zu schnell erfolgt. Ich werde mal den Sleep-Ansatz aus der restart.sh ausprobieren, vielleicht hilft es ja, die Konfiguration rechtzeitig zu sichern.
Hat jemand von euch noch Tipps, wie man die Logs besser im Griff behält, um den RAM-Verbrauch nicht unnötig zu steigern?

rudolfkoenig

ZitatSpeicherverbrauch steigt bei mir auch stetig, insbesondere bei den Shelly-Geräten,

Vorschlag:
- erst das Anwachsen im aktuellen Zustand protokollieren
- dann die Shellies solange abklemmen, bis man anhand des Protokolls eindeutig nachweisen kann, dass die Shellies ein Problem sind.
- die Definitionen der Shellies mit Attributen (siehe copy for forum.fhem.de) und die Shellies betreffenden Logzeilen hier posten
- ich versuche das Modul zu verstehen, und es auf ein Speicherloch zu untersuchen.

Guybrush

welcher Wert wird denn da gemessen? der freie oder der verfügbare speicher?

free memory ist ggf. verwirrend, da das nicht der eigentliche freie speicher ist. sofern verfügbar nutzt linux available memory um sachen im cache zu halten. available memory - caches (ohne swap) ist der free memory. um die ram auslastung zu überwachen sollte also nur available geprüft werden.

vielleicht liegts ja daran...