Cannot fork: Cannot allocate memory | BlockingInformParent

Begonnen von Burny4600, 14 Februar 2018, 10:33:06

Vorheriges Thema - Nächstes Thema

Burny4600

#255
@Damian
Ich habe deine 98_DOIF.pm getestet, aber keine Verbesserung feststellen können.
Sowie ich den Belastungstest starte steigt der Speicherverbrauch.
Wenn ich eine längere Zeit den Testlauf nicht beende wird der Speicher nicht mehr frei gegeben. Er bleibt auf dem letzten Level stehen.
Nur bei kürzeren Tests kann ich feststellen das wieder weniger Speicherverbrauch aufscheint.
Siehe Anhang.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

Damian

#256
Das Problem kann ich alleine durch das Verzögern einer Anweisung mit einem Wait-Timer provozieren.

Der interne Aufruf sieht aus meiner Sicht ungefährlich aus:

InternalTimer($next_time, "DOIF_SleepTrigger",$hash, 0);

Das Löschen des speicherfressenden DOIFs gibt keinen Speicher frei. Ich weiß nicht, ob der $hash dann gelöscht wird, wenn ja, dann wird der Speicher vermutlich in fhem.pl verbraucht.

Ich kann z. Zt. nur rudimentär Analysen betreiben, da ich im Urlaub bin.



Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Burny4600

Da bleibt nur zuwarten bis eine Lösung gefunden wird.
Momentan habe ich noch keine Lösung gefunden um die PWM Ausführung im DIOF anders zu lösen.

ZitatDas Problem kann ich alleine durch das Verzögern einer Anweisung mit einem Wait-Timer provozieren.
Das heißt ohnehin das hier ein Bedarf ist das dieser Fall nicht eintreten soll.
Zum einen soll der Speicherverbrauch nicht ständig steigen und zum Anderen sollte der vorher benötigte Speicher nach einem Halt der Funktion wieder frei gegeben werden.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

Damian

Hier mal eine einfache Definition zum Analysieren, die zum Speicherverbrauch führt:

defmod a at +*00:00:01 set bla  on

defmod b DOIF ([bla:"on"])(set bla2 on)
attr b do always
attr b wait 0.5


bla, bla2 sind Dummys

Dass at keinen Speicherverbrauch produziert, hat Rudi schon festgestellt. Das DOIF reagiert auf das Event "bla: on" und setzt um eine halbe Sekunde verzögert set bla2 on. Ohne Verzögerung durch das Attribut wait wird kein Speicher verbraucht.


Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

#259
Ich habe einen workaround gebaut. Bitte testen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Nighthawk

#260
Hallo Damian,

danke für deine Arbeit, leider behebt der Fix, zumindest bei mir, nicht das Problem.

Wie man auf dem Bild im Anhang sieht, habe ich um 22:30 auf zu Stretch gewechselt und der Speicheranstieg ist sofort wieder da.

Burny4600

#261
@Damian

Einen Teilerfolg hat die Änderung gebracht.
Was mich verwundert ist das es beim Pi2+ keinen steigenden Speicherverbrauch mehr gibt. Auch die Belastung der CPU ist geringer die sich anhand der Temperatur auch bemerkbar macht weil diese jetzt geringer ist.
Man sieht sehr schön bei diesem Test wie ich das PWM Dummy aktiviere steigt die CPU Frequenz und Temperatur, aber der Speicherverbrauch bleibt nahezu gleich.

Beim Pi3+ ist aber mit der gleichen Konfiguration außer die Pi3+ spezifischen Softwarepakete aber keine Änderung bemerkbar. Hier wird der Speicher verbraucht bis nichts mehr geht was die Aufzeichnungen der Plot betrifft.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

Damian

#262
Zitat von: Burny4600 am 29 Mai 2018, 11:56:24
@Damian

Einen Teilerfolg hat die Änderung gebracht.
Was mich verwundert ist das es beim Pi2+ keinen steigenden Speicherverbrauch mehr gibt. Auch die Belastung der CPU ist geringer die sich anhand der Temperatur auch bemerkbar macht weil diese jetzt geringer ist.
Man sieht sehr schön bei diesem Test wie ich das PWM Dummy aktiviere steigt die CPU Frequenz und Temperatur, aber der Speicherverbrauch bleibt nahezu gleich.

Beim Pi3+ ist aber mit der gleichen Konfiguration außer die Pi3+ spezifischen Softwarepakete aber keine Änderung bemerkbar. Hier wird der Speicher verbraucht bis nichts mehr geht was die Aufzeichnungen der Plot betrifft.

Mein Hack hat nur durch Tests die Symptome  des Speicherverbrauchs, die ich aufgrund meiner hier geposteten Testkonfiguration nachvollziehen konnte, beseitigt. Die Ursache des Problems ist mir nicht klar und scheint tief in Perl (möglicherweise versionsabhängig) begraben zu sein, siehe: https://forum.fhem.de/index.php/topic,88208.msg806196.html#msg806196
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Burny4600

Das ist wirklich eine hartnäckige Angelegenheit.

Ich werde mit dem Pi3 einige Vergleiche machen wo es grundlegende Unterschiede noch gibt.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

Damian

Zitat von: Burny4600 am 29 Mai 2018, 20:55:08
Das ist wirklich eine hartnäckige Angelegenheit.

Ich werde mit dem Pi3 einige Vergleiche machen wo es grundlegende Unterschiede noch gibt.

Ich werde versuchen den Programmiercode so abzuändern, dass die Verzögerungsangaben in wait nicht bei jedem Trigger über regex-Abfragen ausgewertet werden, sondern nur bei Änderungen. Das könnte neben Performancegewinn das Problem beheben, wenn es nicht noch mehr tickende Zeitbomben in Perl gibt ;)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

mumpitzstuff

#265
Wenn man mal intensiver danach sucht, dann findet man einige Bug reports in Bezug auf memory leaks in den unterschiedlichsten Perl Versionen. Interessant wäre nun, welche Perl Versionen auf den Rechnern installiert sind, bei denen das Problem auftritt und welche Perl Version bei denen wo das Problem nicht auftritt. Vielleicht kann man daraus ja was ableiten.
Wobei man natürlich beachten muss, das bei diesem Problem immer 2 Dinge zusammen kommen müssten: die fehlerhafte Perl Version + ein Modul das den Fehler auslöst. Vielleicht gibts aber jemanden der die gleichen Module auf 2 Rechnern verwendet, bei denen sich nur die Perl Version unterscheidet und bei einem läuft es und beim anderen gibts einen Speicherzuwachs.

Nighthawk

Also ich habe mittlerweile ein Raspi3 mit einem USB-Stick auf dem auf 2 Partitionen Raspbian Jessie und Stretch drauf ist und ich dazwischen springen kann.
Die FHEM Konfiguration wird jedes mal vor einem Wechsel kopiert, daher immer genau gleich.

Auf Raspbian Jessie läuft perl 5, version 20, subversion 2 (v5.20.2) ohne Probleme.

Auf Raspbian Stretch ist es  perl 5, version 24, subversion 1 (v5.24.1) mit dem Speicherzuwachs.

rudolfkoenig

Wenn man nach "perl 5.24 memory leak" im Internet sucht, dann tauchen einige Meldungen auf.
Kannst du bitte den "Crosstest" machen: auf Stretch 5.20 oder auf Jessie 5.24 installieren?
Mit ActivePerl koennte man auch einfach 5.26 testen.

Nighthawk

Hallo Rudi,

kannst Du mir sagen wie ich es am elegantesten hinbekomme das 5.24.1 down zu graden?

Danke und Gruß
Alex

rudolfkoenig

Ich wuerde ein ActivePerl Paket (.tar.gz) herunterladen, es irgendwo auspacken, und mit diesem perl testen (cd /opt/fhem; ...ActivePerl-5.20/bin/perl fhem.pl fhem.cfg).