Cannot fork: Cannot allocate memory | BlockingInformParent

[mumpitzstuff]

In welchem Zusammenhang verwendest du XML::bare? Wenn man das falsch verwendet, erzeugt das auf jeden Fall Memory leaks, weil die Library einen Bug hat.

https://rt.cpan.org/Ticket/Display.html?id=90562

[towag]

Seit gestern Abend gibt es keinen Anstieg im Speicherverbrauch mehr. Das Auskommentieren des UNIFI-Controllers und der Switch-Definitionen hat bei mir scheinbar geholfen.

[MadMax-FHEM]

Was für ein System?
Perl-Version?

Auf meinem "Speicher-Testsystem" mit "nur" UnifiControler, UnifiClient, Tradfri, Zoneminder kann ich nichts dergleichen beobachten...

Raspberry PI 3 (ohne Plus), Stretch und Perl v5.24.1

Gruß, Joachim

[clumsy]

Nach ersten erkentnissen hat u.a. auch das DbLog evtl. noch Probleme. Nach 12h steigt der Memoryverbrauch von FHEM von 180M auf 1100M an. Nach einem Reload von DbLog sind es immerhin nur noch 900M... den Rest konnte ich noch nicht lokalisieren.

So wies aussieht ist das Problem wohl an mehreren orten. Evtl. sogar in einem drunterliegenden verwendeten Perl-Modul (ich verwende 5.28.1).

[JoeALLb]

Nach 12h steigt der Memoryverbrauch von ...

Nun, bist Du dir da sicher? DbLog benötigt für das Cachen der Logeinträge natürlich Speicher, vermutlich deshalb auch mehr speicher als andere Module.
Aber dass der Speicher unkontrolliert anwächst stelle ich nicht fest!
Ich kenne diese Schwierigkeiten auch im Zusammenhang mit anderen Modulen, habe diese aber mittlerweile deaktiviert und komme so auf sehr lange Uptimezeiten....

Joe

[clumsy]

Nun, bist Du dir da sicher?

Nein, bin ich natürlich nicht, deshalb bin ich am suchen...

DbLog benötigt für das Cachen der Logeinträge natürlich Speicher, vermutlich deshalb auch mehr speicher als andere Module.

Das ist klar, dann müsste es aber immer in etwa gleich viel sein, was nach einem reload des DbLogs weggeht... aber je länger ich warte desto mehr reduziert der reload von DbLog das Memory...

Aber klar, alles nur heuristische Behauptungen bisher... es muss irgendwo noch etwas sein (zum. bei mir) da es so ca. 1M/min. ansteigt (ca. 1GB nach 12h)

[DS_Starter]

Wie Joe schon schrieb müsst ihr bei DbLog berücksichtigen ob ihr es im asynchronen oder synchronen mode betreibt. Je nachdem wie oft ihr im asynchronen mode die update Zeiten eingestellt habt, werden die Daten in der Zwischenzeit im Speicher gehalten und dann gelöscht. Es gibt dann also ein ständiges Auf und Ab des Speichers. (200 MB wären aber m.M. nach zuviel) Ein permanentes Ansteigen des Speichers darf aber nicht auftreten.
Wenn ihr unsicher seid, deaktiviert den asynchronen mode temporär. Dann werden die Daten nicht gecached.

Wichtig ist auch noch zu wissen, das unterschiedliche Datenbankbibliotheken je nach verwendeten DB-Typ vom Modul genutzt werden. Sollte dort ein Leak verborgen sein, würde ein MySql User zum Beispiel kein Problem haben, ein Postgre User eventuell. Nur damit ihr das etwas einordnen könnt und nicht global "draufspringt".

Ich behalte es trotzdem mal im Hinterkopf bzw. hatte wegen dieser Problematik in der Vergangenheit bereits im Modul geschaut aber bisher keine verdächtigen Stellen erkennen können.

Grüße,
Heiko

[clumsy]

Wie Joe schon schrieb müsst ihr bei DbLog berücksichtigen ob ihr es im asynchronen oder synchronen mode betreibt. Je nachdem wie oft ihr im asynchronen mode die update Zeiten eingestellt habt, werden die Daten in der Zwischenzeit im Speicher gehalten und dann gelöscht. Es gibt dann also ein ständiges Auf und Ab des Speichers. (200 MB wären aber m.M. nach zuviel) Ein permanentes Ansteigen des Speichers darf aber nicht auftreten.
Wenn ihr unsicher seid, deaktiviert den asynchronen mode temporär. Dann werden die Daten nicht gecached.

Wichtig ist auch noch zu wissen, das unterschiedliche Datenbankbibliotheken je nach verwendeten DB-Typ vom Modul genutzt werden. Sollte dort ein Leak verborgen sein, würde ein MySql User zum Beispiel kein Problem haben, ein Postgre User eventuell. Nur damit ihr das etwas einordnen könnt und nicht global "draufspringt".

Absolut klar, ist ja auch keine Kritik am Modul oder gar eine "Schuldzuweisung"

Ich verwende MySQL (resp. MariaDB), da gabs auch immermalwieder probleme bei den connectoren... das kann natürlich auch sein..

Werd aber mal auf synchron umstellen, mal sehen was dann passiert..

Und danke schonmal erstens für die Hilfe und zweitens fürs Modul

[DS_Starter]

Absolut klar, ist ja auch keine Kritik am Modul oder gar eine "Schuldzuweisung"

Alles gut, habe ich auch nicht so verstanden.    Wir tappen ja alle irgendwie im Dunkeln und versuchen etwas zu finden was weiterhilft. Und kann ja auch hier noch etwas verborgen sein, nobody is perfect !

[HomeAuto_User]

Hallo,
ich melde mich auch noch einmal zu Wort.
Ich habe mal ein Update gemacht, nachdem Rudi etwas fixte.

Bei dem Modeul HTTP Mod welcher 99 Readings auslesen soll bringt das ganze nicht. Ich kann auf jedenfalll reproduzieren, wenn ich das Modul auf disable 1 stelle, das mein System läuft. Wenn ich das Modul laufen lasse und disable deaktiere, so kommt der Fehler

Code Auswählen Erweitern

Cannot fork: Cannot allocate memory nach kurzer Zeit. Ich denke wir suchen einen Prozess der intern von Perl verwendet wird und zu dem Fehler führt.

Ich kann es nur wiederholen, wenn man mir Input´s geben könnte, wie man das ganze erforschen kann, so bin ich gern bereit aktiv mit zu helfen.
Gibt es Ideen oder Programmteile in Perl welche unter Verdacht sind?

MfG

PS: Bis dato folgt nun wieder Modul auf disable == 1 .... ist aber nur ein Workaround

[towag]

Mein System: Raspberry 3B+, Stretch
FHEM: Server started with 318 defined entities (fhem.pl:20069/2019-08-27 perl:5.024001 os:linux user:fhem pid:3769)

Seit gestern Abend ist die Speicherkurve sehr flach (um 17:05 war der Cron-Restart, den ich heute wieder stillgelegt habe)
Ich hoffe, dass das System nun ein paar Tage durchläuft. Danach werde ich nochmal einen MemoryDump ziehen.

Danach werde ich nur den UNIFI-Controller wieder einbinden ohne die Definitionen für die Switches.

[CoolTux]

Hallo,
ich melde mich auch noch einmal zu Wort.
Ich habe mal ein Update gemacht, nachdem Rudi etwas fixte.

Bei dem Modeul HTTP Mod welcher 99 Readings auslesen soll bringt das ganze nicht. Ich kann auf jedenfalll reproduzieren, wenn ich das Modul auf disable 1 stelle, das mein System läuft. Wenn ich das Modul laufen lasse und disable deaktiere, so kommt der Fehler

Code Auswählen Erweitern

Cannot fork: Cannot allocate memory nach kurzer Zeit. Ich denke wir suchen einen Prozess der intern von Perl verwendet wird und zu dem Fehler führt.

Ich kann es nur wiederholen, wenn man mir Input´s geben könnte, wie man das ganze erforschen kann, so bin ich gern bereit aktiv mit zu helfen.
Gibt es Ideen oder Programmteile in Perl welche unter Verdacht sind?

MfG

PS: Bis dato folgt nun wieder Modul auf disable == 1 .... ist aber nur ein Workaround

Fuer Leute mit Kommandozeilen-Erfahrung: die zweite Antwort aus https://askubuntu.com/questions/152716/how-to-detect-a-memory-leak (das mit /proc/$pid/smaps) scheint fuer mich praktikabel zu sein, wobei Schritt 7 mAn ueberfluessig ist. Ich meine eher, dass man das Verfahren (mit gebuehrenden Abstand) zweimal anwenden muss, damit man feststellen kann, was dazugekommen ist.

Rudis Link ist doch gut beschrieben. Haben sogar ein paar Leute ohne Nachfrage hinbekommen.
Solltest Du da Probleme mit haben müsstest Du bitte warten.

[rudolfkoenig]

Bei dem Modeul HTTP Mod welcher 99 Readings auslesen soll bringt das ganze nicht.

Das wuerde auch an einem Wunder grenzen, da ich nur FHEMWEB angefasst habe.

Ich kann es nur wiederholen, wenn man mir Input´s geben könnte, wie man das ganze erforschen kann, so bin ich gern bereit aktiv mit zu helfen.

Ich kann ja auch nur wiederholen
- /proc/$pid/smaps auslesen (https://forum.fhem.de/index.php/topic,84372.msg970863.html#msg970863)
- Modul mit reload pruefen (https://forum.fhem.de/index.php/topic,84372.msg971563.html#msg971563)


Uebrigens ist es nicht so, dass wir ganz genau wissen,wie man die Ursache findet, und wir es nur nicht verraten wollen.
Eher andersherum: wir tappen weiterhin im dunkeln. Ich habe nur eins der vielen unterschiedlichen Loecher gestopft, die jeweils nur wenige Leute betreffen.

[rudolfkoenig]

@Hardlife: koenntest bitte mit dem neuen FHEMWEB wieder ein memdump erstellen?

[Hardlife]

@Hardlife: koenntest bitte mit dem neuen FHEMWEB wieder ein memdump erstellen?

Kein Problem...
Danke für die Unterstützung.

Anbei ein Memdump, den ich gerade angefertigt habe.
- Messdauer ca. 15 Minuten
- Speicheranstieg während Messzeit ca. 6MB

LG,
Hardlife